Konzentriert sich Ihr Sicherheitsprogramm auf die Reaktion auf Vorfälle? Sie machen es falsch.

A version of this article appeared as a feature for the Forbes Technology Council. It has been updated and syndicated here.

‍

There is nothing quite like being on the wrong side of a data breach. At first, there might be denial, then panic. Once all the expletives have been aired and the CISO has had to do a 2am conference call with public relations, it’s time to roll up your sleeves and get to work on securing endpoints, systems, and quickly eliminating any potential attack vectors. It’s no picnic, to say the least. 

And yet, this is a reality that will dawn on many organizations in the future, and one that absolutely must be prepared for with a comprehensive cybersecurity incident response plan. The problem, however, is that this reactive strategy is where much of the time, resources, and effort is concentrated, instead of working to prevent or reduce the potential severity of cyberattacks up-front. It’s a little bit like calling an ambulance for a suspected heart attack; the outcomes are often a lot less positive - not to mention more damaging - than if preventative health measures were in force before it was too late. 

To that end, what does a preventative plan look like? Let’s explore how security pros can employ all the tools at their disposal to mitigate ever-increasing cyber risk, every day:

Understand the scope of work that lies ahead 

It seems obvious, but the “right” plan to mitigate cyber risk does have nuances between industries, and it’s important to understand what is needed up-front to reach the desired outcome.

What security problems currently exist? What time and resources are they taking up? How many of them are recurring issues? These are important factors, and will give you a foundational starting point. Consider any roles that need filling, gaps in tooling, and what is needed from an expertise and tool perspective to secure endpoints and reduce the attack surface, while preempting other areas of potential risk. 

A recent report revealed that eleven industries saw a serious vulnerability, across at least half of their applications, every day for the past year. In particular, the utilities, public administration, and professional services industries took 288 days on average to patch known vulnerabilities. This is incredibly slow, giving an attacker more than enough time to do serious damage if those vulnerabilities are discovered before a patch can be applied. This, coupled with the probability of organizations experiencing a data breach approaching 30%, is a sobering reminder that incident reaction is not enough, and the stakes are simply too high to brace for the impact of a large-scale cyberattack and hope for the best.

Prepare to get buy-in for cultural change

Shaking up the status quo does tend to raise a few eyebrows, but the truth is, security programs should be in a constant state of continuous improvement. Every component should stay relevant, and new developments should be assessed and factored in. 

Placing emphasis on a preventative - as opposed to reactive - approach may not be widely understood outside of the security team, especially if a big, bad, security incident has not taken place. It might be seen as something that isn’t broken and doesn’t need fixing. In this instance, getting executive buy-in is essential. Some of the more pertinent points for them to consider are:

• The time and cost savings in preventative measures, such as role-based training and related tools, as opposed to the potential cost of a critical incident 
• How finding and fixing vulnerabilities now keeps releases on time, with fewer showstoppers from the security team
• Why preparing for and preempting potential security risks, from the development team right through to release, saves more time (no to mention significant cash) overall. To put it into perspective, late-stage vulnerabilities uncovered in the testing phase - or worse, post-production - can raise costs as much as 3000% on average.
  

It’s vital that proposed cultural changes are aligned with business goals, even if they seem uncomfortable at first. 

Security awareness is something, security skills are everything

As an industry, we talk frequently about the importance of security awareness, and this is an increasingly critical component of every member of staff in an organization. However, it is not enough to stop at lip service and passive training, especially for those in technical positions.

Put simply, anyone who is touching code is a potential security risk if they’re not equipped with the skills to code securely. General awareness of basic security parameters is a good start, but without contextual knowledge of good, secure coding patterns, poor habits prevail, and it’s this lack of quality development skill that attackers rely upon to do their dirty work. 

Don’t write off your developers.

Though the attitude is shifting, many organizations are structured in such a way that developers are rarely a true consideration in security mitigation plans. Some industries - like banking and finance - have stringent compliance and regulatory requirements that result in heightened security practices and training across the board, for all staff. And while they’re certainly ahead of other verticals, just about every organization on the planet could benefit from an in-house army of security-aware developers, all with a baseline ability to sniff out common security bugs before they’re committed. Most are nowhere near achieving this critical piece of the security program puzzle - and it’s necessary if we ever have a hope of securing the deluge of code that increases in volume year-on-year.

Preventative security should begin the moment fingers touch the keyboard to create software, but developers cannot be expected to bridge the security skills gap alone. They need the right toolset and contextual guidance to reach a higher standard of code quality, and the best results are always achieved when it’s part of their everyday work, not an afterthought that is sporadically rolled out whenever annual compliance requirements roll in.