Last week Michael Price, Ahmed ElAshmawy and Chris Blunt from Axenic were fortunate enough to make the trip across the Tasman to Sydney for the 2nd annual COSAC APAC Security Conference. All 3 had the chance to speak to the attendees and without any bias, Michael shares his take on the Top Talk and some other notable mentions.
In my previous two articles in this series focused on developing an Information Security Management System (ISMS) based on ISO 27001:2013, I presented the common myths associated with the standard. In this article, I am going to provide an overview of the standard and section 4 Context of the organisation.
Okay, I know I promised to delve into and discuss the requirements defined in 4 Context of the organisation. However, I realised that they are other common myths that I should dispel for those of you that are interested in implementing an Information Security Management System (ISMS) that conforms with ISO/IEC 27001:2013 (ISO 27001).
This is the fourth article in a series that aim to help organisations build and maintain their information security incident management and response capability.
In the previous article I provided a bird’s eye view of the standard incident handling process. As noted previously, the incident handling process is triggered either by detecting or reporting security events. A number of security professionals believe that detecting an incident means looking for failure logs such as failed login, failed resource access etc.
This is the third article in a series that aims to help organisations build and maintain their information security incident management and response capability.
Before getting “into the weeds” of an incident handling process, it is useful to have a bird’s eye view of what it looks like. In this article I will provide you with an overview of the process and a brief description of each of the process steps. While incident handling is widely perceived to be a technical process, only some of its steps require technical knowledge. In reality, a lot of incidents do not require any technical knowledge to handle them. For example, incidents that relate to policy violations, physical security breaches, loss of computing devices, etc.