News & Thoughts from the Axenic Team
With the fast-paced business style, organisations nowadays heavily rely on third parties such as vendors, suppliers, logistics partners, cloud services providers, etc. These partnerships can offer great benefits but also could expose your organisation to risks. That’s where third-party risk management (TPRM) comes into play. TPRM provides a structured approach to evaluating and mitigating these potential risks.
Ready to take control and protect your business? Let’s dive into the world of TPRM!
Recently I’d been helping a customer negotiate their cyber security insurance – which turned out to be trickier than I expected. This got me thinking about the role that insurance played in cyber security. Then – coincidentally – I was reading a book on security (Paul Martin’s great “The Rules of Security”) and came across this sentence: “Insurance is sometimes described as a means of transferring risk, but it is really more of a mechanism for softening the financial impact of a loss.” (p 73). It got me wondering – at Axenic have we been thinking about insurance all wrong?
Information security is all about context!
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.
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.
This is the second 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 introduced the issue of the general deficiency of effective incident management and response processes in many organisations. But what is a security incident? The short answer is: it depends! It is up to each organisation to define what kinds of events it determines to be a security incident.