When you look at your business strategy from a high level, everything seems straightforward and easy. Goals can be clear and express business value, the road map can push your teams with achievable goals, and key performance indicators (KPIs) can be selected to measure and promote success. At a high level, combining business and security is both achievable and commonsensical.
When you dive down into the nitty-gritty details, however, accomplishing those plans is another matter. Your goals will depend on your business and the industry in which you are operating. If you are working for an online financial institution without internal development, for example, security practices will likely be highly compliance-driven and your risks mitigated by service-level agreements (SLAs).
Yet, once you add internal development, everything changes. Without the stick of compliance, executive support—not to mention security awareness—will likely be subpar. Does your company prioritize implementing information security or just meeting regulations? Does your application security program also address acquisitions?
It's important to realize why security is a requirement for your organization—your goals must serve a purpose. Focusing on compliance without a security mindset will result in operational expenses that do not meet security goals. For that reason, understanding the reasons for incorporating security into your business is critical to achieving cyber resilience.
Turn compliance into an asset
Your application security strategy can be as simple as complying with government regulations or meeting industry best practices. Yet compliance without a security focus will end up being a cost center that does not provide value.
Compliance can drive security, however. Because industry and government regulations are mandatory, security groups can use the requirements to fund security initiatives that also satisfy regulations. While many businesses don't understand the risk posed by the broad landscape of cyber threats, they do understand the risks of not complying with regulation.
Increasingly stringent and pervasive privacy regulations, while designed to protect citizen data and privacy, pose penalties related to data leakage. However, the rules seldom provide guidance on the "how." Industry standards tend to have more detailed requirements in security measures and practices, but they struggle with the balance between reaching the required depth for measures to be meaningful and maintaining common applicability.
The security practice lead—whether the chief information security officer (CISO) or the head of application security—should talk to the legal and business groups about what government regulations require and to the sales department about customer expectations. Quite likely, your customers will have some opinions about such security standards, so don’t be surprised to find references to compliance and industry regulations already included in contracts. Depending on your company’s business maturity, it can be a tedious exercise, but it will be worth it.
What's required?
Most companies will have to adhere to various compliance legislation and industry standards. The most common are the Payment Card Industry Data Security Standard (PCI-DSS), the European Union's General Data Protection Regulation (GDPR), or one of the US states' various privacy laws, such as the California Consumer Privacy Act (CCPA). Customers using your application or services might require the software’s quality to meet the ISO 25010 standard.
What's required under the various standards will often be similar or even the same—understandable, given that each law, standard, and best practice is trying to achieve the same goal. Many of them offer a more detailed specification the others contain or a forked version of it. Therefore, organizations should first investigate the broad requirements for each set of requirements to which the company must abide, instead of setting up separate projects for each.
Having a holistic overview on the relevant regulations and the resulting requirements gives you an n-to-n relationship, with each regulatory regime requiring many security measures and each security measure being required by many regulatory regimes. By matching security measures to the relevant regulations in a simple matrix, repetitive discussions about "Why do we need to do this?" can be eliminated, or at least reduced. "It is a compliance requirement" is a simple but effective answer. In addition, if inquiries into customers' security requirements resulted in a separate list of measures, the resulting overview will make your life easier by answering those as well. Of course, this will increase the quality of your own security inquiries to your suppliers as well.
Pro-tip: When adding your implementation and operating costs to the matrix, include license fees and the needed number of full-time employee (FTE) equivalents. This gives you the ability to defend your security budget by justifying security costs in terms of compliance requirements.
From measures to measure
As previously mentioned, most measures are required by various standards and regulations. It is one thing to implement various measures as requirements, another to use the implemented measures to advance application security maturity. You must test your security controls and adjust them periodically to maintain compliance, because the required measures might change as your environment evolves. Consistently adapting to the threat landscape and compliance requirements will allow your organization to improve and become more mature.
Improving security maturity and the compliance validation process also will help you verify the real security maturity of your suppliers during security audits and aid in estimating the business risk in acquisitions. Keep in mind, a security audit should not just be about checking boxes and providing a paper trail. Because vendors can answer a security questionnaire in various ways, your organization should follow up to ensure that they are following the intent of any requirements.
Put tools into action
Organizations can measure the security maturity of their internal or external development groups using the OWASP Application Security Verification Standard, which gives you the metrics and guidance to measure or improve application security, or to produce a list of requirements for procurement.
The Application Security Wayfinder, a deliverable of the OWASP Integration Standard Project, is linking requirements and guidance across standards through the Common Requirement Enumeration. The OWASP Project map gives you an overview on how to link projects to the secure development lifecycle.
This is the third in a series of posts about leveraging DevSecOps in your business to reduce sleepless nights for CISOs and application security managers, while reducing friction with security teams and maintaining agility and speed of delivery for development. The goal is to guide CIOs, CTOs, and CISOs and achieve a win for everyone: faster delivery of more secure, and therefore higher-quality, software as well as oversight and control regarding the enterprise software assets.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
