The average cost of a security breach in the US is $8.19M. That’s a significant number to the bottom line for any company. These aren’t one-offs either. Every industry is facing frequent attacks… nearly 90% of healthcare companies are actively being hacked. 75% of retail and 60% of manufacturing companies are facing varying degrees of digital attacks.
Why is this? The amount of accesses to products and information, and the demands of customers in this environment forces companies to expose more and more doors to bad actors. Major entry points are “not-so-secure” software. There’s also unintentional insiders, having access, not knowing the aspects of security practices. Back doors are often found that way.
Lastly, there’s a paradox between Agile (or Agile-like) teams wanting to ‘go fast’ and ‘innovate/react’ quickly to market demands, and doing it while maintaining appropriate security measures. Security must be an integral and important part of the processes and workflows present in an organization, therefore security woven into collaboration is key.
There are Three Pillars to Security… Culture, Process, and Tools
For culture, everyone must be accountable toward security. It’s about information-sharing, teamwork, and breaking down information silos. Security cannot be a separate team AND an afterthought… or something you bolt on to a product. Build it IN the product.
What’s the goal of an organization? For many, it’s to build high-impact, high-value, secure products. All good products espouse confidentiality, availability, integrity. If the development team is security self-aware, you are half-way there. Every module or feature you write needs to have both use cases and ‘mis-use cases.’ Remember, built-in, not bolt on. The security team cannot write these. It must be development’s job, given they are closest to the customer use cases and the product mapping.
Ask your Development team… what’s your take on security? Is it only for the last leg of the race? Is it a check-box activity? Are your tools in place to validate your answers?
To solve for this… look at the real goal. High quality software cannot be deemed as such without having minimal bugs, compliance, and no security flaws. Security=Quality. Still need to deliver faster? Remember, the only thing that has value… is production code, so modeling the delivery of security in production is paramount.
Dedicate development to write mis-use cases, and then test them with security. When you see things by a testing point of view, you’ll have security in mind. Concerned about products already out there? There are tools for strong feedback loops (logs, telemetry data, trace downs, etc). If you have those things in place, you can have a prediction model for risks. This is realistically a reactive model, but a strong logging process is key
