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 that 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:
1. The importance of cybersecurity education
2. Apply encryption but don’t reinvent the wheel
3. Plan out risk mitigation with threat modeling
4. Secrets are best to be kept away from the code
5. Granularity enables control, but also adds to threat exposure
6. Application security needs to be implemented throughout all SDLC phases
7. The chain is only as strong as its weakest link – treat applications the same way
8. Keep track of the application footprint
9. Track application load, stress, and resiliency
10. Confirm the app can meet the business objectives in production runtime
1. The importance of cybersecurity education
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.
2. Apply encryption but don’t reinvent the wheel
It is everyone’s responsibility in an organization, 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.
3. Plan out risk mitigation with threat modeling
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.
4. Secrets are best to be kept away from the code
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.
If you are a CTO looking into security, try to utilize a secrets management framework, perhaps along with a dedicated SaaS or PaaS solution, that allows for secure storing, sharing and delivery of intangible assets to the application.
5. Granularity enables control, but also adds to threat exposure
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.
6. Application security needs to be implemented throughout all SDLC phases
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.
7. The chain is only as strong as its weakest link – treat applications the same way
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.
8. Keep track of the application footprint
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.
9. Track application load, stress, and resiliency
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.
10. Confirm the app can meet the business objectives in production runtime
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.
