To determine an organisation’s application security (AppSec) maturity level, begin by understanding the acceptable risk levels defined by the industry in which it operates. For example, healthcare providers need to comply with the regulatory requirements as set by the relevant governing body; the same applies to financial institutions, etc.
The AppSec maturity evolution isn't achieved by simply implementing new technologies or automating specific processes. It requires a combination of technology, automation, capabilities, people, processes and culture. However, AppSec maturity can be accelerated through technology deployments.
Maturing an AppSec programme is complex. Moving through the different levels helps to achieve a mature and optimised programme. When progressing towards achieving a full maturity model, the business will advance through the different stages. Defining the infrastructure is much simpler than identifying security policies.
An AppSec programme evolution model that is only viewed from a technology viewpoint does not represent a mature or optimised AppSec programme. Important controls − such as performance, accuracy, or impact level of each of the capability areas − must be defined. The requirements, policies, processes and technologies are simply grouped by capability.
When the focus is on the type of technology and the lowest level of complexity, it can create a false sense of security. The company needs to ask some questions, including do the capabilities shown enable development teams to eradicate weaknesses and vulnerabilities? Also, can it proactively adapt to the ever-evolving cyber security risk landscape by following this model?
Risks need to be identified in the first phase and applications must be tested, results viewed and reports run that meet all compliance requirements. But without the necessary information to fix vulnerabilities, holes in the security posture will remain, exposing the application to potential abuses.
The company might seek to achieve the risk mitigation phase. However, if the policy compliance phase hasn't been completed to address and quantify technical risk, it is difficult to determine which controls should be enforced. Policies must be defined based on the security needs of the business and its customers.
An AppSec programme evolution model that is only viewed from a technology viewpoint does not represent a mature or optimised AppSec programme.
If capabilities and technology deployment haven't achieved maturity, automation must be considered. It helps improve the use of valuable resources, but it's important to understand that a push-button approach that enables the business to release vulnerability-free software applications doesn't equal maturity.
AppSec maturity isn't a one-size-fits-all model. Depending on the industry, vulnerabilities should be assigned different risk levels. For example, aerospace might view a vulnerability as critical, but the insurance sector might view the same vulnerability as low risk. The resources needed to remediate a critical vulnerability for an aerospace environment would be too expensive to remediate in an insurance company.
Automation, like capability and technology deployment, isn't the complete picture of a mature AppSec model. The Open Web Application Security Project Application Security Verification Standard states that automation often can't complete the entire verification process.
Automated tools and online scans can complete about half of the verification programme without human intervention. If comprehensive test automation for each build is required, then a combination of custom unit and integration tests, along with build-initiated online scans, are used. Business logic flaws and access control testing is only possible using human assistance. These should be turned into unit and integration tests.
The bottom line is that getting things done in a faster and repeatable way doesn't always mean they are being done in a better way.
What does it mean to achieve a mature AppSec model? It can be easy to assume that technology alone will help the business to accelerate its AppSec maturity model.
Moreover, there is an assumption that if all the testing, risk identification and remediation processes are automated, then maturity is reached. That is not necessarily the case. A complete maturity model is only attainable when the following four areas work together: technology, architecture, automation and operation.
Accelerating AppSec maturity requires integrating security policies and structure into each area, starting with the level of maturity the business requires. This all needs to be completed during the planning phase and in collaboration with all stakeholders across the company.
An AppSec maturity programme is included in all the aspects of the software development life cycle and includes the technology, automation and individual capabilities. When constructing a programme, define a roadmap that establishes objectives, deployment timelines, scope and measurements for success.
It is also important to keep objectives achievable and ensure activities are only as complex as they need to be. Finally, make sure to document quick wins and successes.
Moving from one capability maturity model level to the next takes time and resources. Maturing an AppSec programme can take years, but by implementing the type of centre of expertise and operating strategy recommended, the company can accelerate its AppSec maturity model beyond the basic level driven by technology.
It can give the company, its people and customers the confidence to meet regulatory, compliance, customer and business goals. Repeatable processes, standards and remediation plans help businesses to move beyond the basics.
AppSec needs to be ingrained in the company's DNA. AppSec programmes include employees, competitors, processes, vendors, regulations and practices. But achieving AppSec maturity isn't a one-time event. It's an ongoing journey that requires full cooperation from the executives through to the developers.
Share