In the not-so-distant past, banking and healthcare industries were the main focus of security concerns as they were entrusted with guarding our most sensitive personal data. Over the past few years, security has become increasingly important for companies across all major industries. This is especially true since 2017 when the Economist reported that data has surpassed oil as the most valuable resource.
How do we respond to this increased focus on security? One option would be to simply increase the security standards being enforced. Unfortunately, it’s unlikely that this would create substantial improvements.
Instead, we should be talking about restructuring security policies. In this post, we’ll examine how security standards look today and 5 ways they can be dramatically improved with new approaches and tooling.
How Security Standards Look Today
Security standards affect all aspects of a business, from directly affecting development requirements to regulating how data is handled across the entire organization. Still, those security standards are generally enforced by an individual, usually infosec or compliance officer.
There are many challenges that come with this approach, all rooted in 3 main flaws: 1) the gap between those building the technology and those responsible for enforcing security procedures within it, 2) the generic nature of infosec standards, and 3) security standards promote reactive issue handling versus proactive.
We can greatly improve the security landscape by directly addressing these key issues:
1. Information Security and Compliance is Siloed
In large companies, the people implementing security protocols and those governing security compliance are on separate teams, and may even be separated by several levels of organizational hierarchy.
Those monitoring for security compliance and breaches are generally non-technical and do not work directly with the development team at all. A serious implication of this is that there is a logical disconnect between the enforcers of security standards and those building systems that must uphold them.
If developers and compliance professionals do not have a clear and open line of communication, it’s nearly impossible to optimize security standards, which brings us to the next key issue.
2. Security Standards are Too Generic
Research has shown that security standards as a whole are too generic and are upheld by common practice more than they are by validation of their effectiveness.
With no regard for development methodology, organizational resources or structure, or the specific data types being handled, there’s no promise that adhering to these standards will lead to the highest possible level of security.
Fortunately, addressing the issue of silos between dev and compliance teams is the first step for resolving this issue as well. Once the two teams are working together, they can more easily collaborate and improve security protocols specific to the organization.
3. Current Practices are Reactive, Rather Than Proactive
The existing gap between dev and security teams along with the general nature of security standards, prevent organizations from being truly proactive when it comes to security measures.
Bridging the gap between development and security empowers both sides to adopt a shift-left mentality, making decisions about and implementing security features earlier in the development process.
The first step is to work on creating secure-by-design architecture and planning security elements earlier in the development lifecycle. This is key in breaking down the silos that security standards created.
Gartner analyst John Collins claims cultural and organizational structures are the biggest roadblocks to the progression of security operations. Following that logic, in restructuring security practices, security should be wrapped around DevOps practices, not just thrown on top. This brings us to the introduction of DevSecOps.
DevSecOps – A New Way Forward
The emergence of DevSecOps is showing that generic top-to-bottom security standards may soon be less important as they are now.
First, what does it mean to say, “security should be wrapped around DevOps practices”? It means not just allowing, but encouraging, the expertise of SecOps engineers and compliance professionals to impact development tasks in a constantly changing security and threat landscape.
In outlining the rise and success of DevSecOps, a recent article gave three defining criteria of a true DevSecOps environment:
- Developers are in charge of security testing.
- Security experts act as consultants to developers when additional knowledge is required.
- Fixing security issues are managed by the development team.
- Ongoing security-related issues are owned by the development team.
By adhering to these three criteria, organizations can overcome the challenges presented in this post by breaking down silos between dev and security teams, empowering developers to introduce relevant security measures, and shifting left for a proactive approach to security.
One final thought on the key to a successful DevSecOps implementation – monitoring and alerting is key. Reliability engineering is an important part of DevSecOps, so your monitoring and alerting tool should act like the quarterback of your tool stack.
Source: https://www.securitymagazine.com/articles/94314-key-reasons-why-socs-should-implement-policies-over-security-standards
