This article takes a look at the top 10 things a CTO needs to know about application security in order to motivate and grow the maturity of the development environment towards a strong application security posture.
Business models are evolving to tackle the ever-growing challenges of cybersecurity risk and the numerous threats and attack vectors that their environment is exposed to.
The CTO ensures that the application is treated with proper care during different phases of the software development life cycle and later published to production without being exposed to vulnerabilities which could disrupt confidentiality, integrity and availability of the application and digital assets it consists of.
One of the main security-related functions that a CTO contributes to is leading the business functions through a maturity program that differentiates and rates the organization’s ability to address security concerns in the development pipeline.
So, here is a list of the 10 most important things a CTO needs to know about application security which we will cover in more detail:
Many different roles are involved in the process of application development.
Each of those roles influences the life cycle of the application as it goes through phases – from planning to development, and later on from testing to release and production deployment.
Stakeholders need to be introduced to the inner workings of an organization’s security governance as well as the development and operations practices in order to gain a clear understanding of the application’s security risk model and its dynamics in the development life cycle.
It is everyone’s responsibility in an organisation, from the ground up and regardless of size or industry, to ensure that data is safe and to put in measures to ensure maximum control and security to avoid leaks, breaches, and theft – whether they might happen inadvertently or by an adversary with malicious intent.
As data is transferred and stored across application components and the surrounding infrastructure, it is subject to the risk of disruption to its confidentiality.
All stakeholders included in the process of application development must apply verified solutions that deliver the strongest and the most capable encryption solutions.
Reinventing the wheel and breaking encryption algorithms while assuming that the approach will fit a certain use case is a bad idea that could result in the exposure of more than just one sample of the data assets.
In the end, such an approach would bring a higher risk of negative outcomes to both the application as well as the business objectives that the application is delivering.
Threat modeling is the process of identification and analysis of different risk factors that apply to a certain scenario that is considered likely to happen if security controls are implemented inadequately or are not implemented at all.
Threat modeling guides the risk analysis to determine the likelihood and the impact of threat agents affecting a certain asset by exploiting an identified vulnerability.
With this approach, mitigation of risks can be effectively planned and executed to deliver the right measures for prioritizing the implementation of security controls which prove themselves as a benefit rather than a cost.
What exactly makes something a secret?
In terms of application security, a secret is an intangible asset that is classified as a part of a wider asset management framework and an asset security policy that strictly defines how the asset is to be governed securely in terms of storage, transfer and access regulations.
Most often, an application asset that is considered “secret” is a set of credentials that are used for authentication.
In such a context, the secret can be exposed by hardcoding it right in the application code base or by delivering it to the application over environment variables, which is best avoided to minimize the likelihood of leaking data.
It is advised to utilize a secrets management framework, perhaps along a dedicated SaaS or PaaS solution, that allows for secure storing, sharing and delivery of intangible assets to the application.
Services, hosts, and networks are often split and spread out over different locations and environments in order to provide tighter control and more effective governance over smaller units.
This especially the case when decomposing applications into microservices – each microservice can have its own controlled life cycle and its own environment, but it still exposes additional entry points that are susceptible to the exploitation of vulnerabilities.
Addressing application security concerns is done through the engagement of all stakeholders within a development environment through all phases of the software development life cycle.
Everyone involved with the pipeline is required to keep the standard of security-related activities that follow the application to production release in such a way that the core business objectives are not being dragged down because of it.
In a DevOps methodology, this is achieved through DevSecOps – a pipeline that allows for the integration of security testing into the processes and functions of development and operations.
Such a pipeline is defined by a maturity model that describes the levels of commitment and engagement with security in a development environment, as well as the objectives that are to be met if all phases of the life cycle are able to adequately address security concerns.
A mistake often made when addressing security concerns of an application is limiting the scope of protection to the obvious points of access, such as the APIs.
Applications that are deployed over multiple environments, hosts and networks create an enormous attack surface due to the introduction of new service listeners, open ports and communication paths.
As the application evolves through its life cycle, it grows the codebase and the data stores along with the changes in its structure, configuration and runtime behavior.
The complexity of these dynamics requires assessing and mitigating security risks that might affect all components the application interacts with.
It is recommended to implement a framework that boosts the maturity of the organization’s security posture such as the OWASP SAMM in parallel with the addressing of the OWASP Top 10 risks and vulnerabilities.
Continuous integration and continuous delivery (CI/CD) drive the modern software development life cycle at a fast pace, resulting in the constant growth of the application and the resources it uses, such as data stores, third party integrations and package dependencies.
All of the aforementioned should be trimmed to give the smallest footprint possible in order to reduce the attack surface and avoid wasteful usage of resources, thereby improving the efficiency of application development and speeding up the release cycles.
The data that the application stores, transfers and manipulates with its other assets with its own life cycle should be regularly purged according to a predefined data retention policy.
Deploying the application to production and exposing it to public access increases the likelihood of service downtime due to the increase in workload.
As the amount of incoming traffic grows and the number of different interactions is introduced to the application, the underlying resources are likely to eventually fall down under the weight of tasks and functions the components are required to perform.
Implementing a monitoring system that can track events and deliver actionable metrics will enable visibility over the application, providing insight into where the bottlenecks are and how exactly the added load affects each component.
Additionally, the application entry points are susceptible to fuzzing attacks which can cause application crashes, error conditions and malfunctions in the application’s runtime behavior by injecting malformed or invalid data that the entry point probably did not expect as input.
Such concerns can be addressed by applying a fuzzing solution to a security testing phase of the software development life cycle.
Development pipelines establish a testing phase that is prior to application release.
In that phase, the security posture of the application needs to be assessed by scanning the application end-to-end to detect and expose vulnerabilities in the application’s entry points and business flow logic.
End-to-end scanning coverage is achieved with Dynamic Application Security Testing which can confirm that the application is able to meet its business objectives in production runtime without being exposed to any vulnerabilities.