All the experts agree – cyber security should be an organisation-wide concern. And yet, in my experience too many organisations, and too many people in those organisations think that cyber security is solely the concern of (a) the security team, or (b) the IT/digital team. In case you need convincing my favourite response is that if there is a cyber-attack (or incident) then it is not the IT team’s job that is at risk, but part of the organisation (if the HR system is compromised it is the HR team who won’t be able to work, not the IT or security teams). Who knows what the impact is of an attack? It’s not IT, that’s for sure. And who is best placed to balance off the needs of the organisation with the cyber risks? It’s not security: if you left it up to me, I’d turn everything off! That’s the only way to be sure (and I get no benefit from it being on, so…)
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.