Developing an application is anything but trivial. It takes time, effort, and creativity to create the right balance of form and function. Complicating things further is the trend to shift security left and into the hands of the developers that are building the application. Developers aren’t security professionals, yet they are tasked with building secure applications.

Here are a few considerations CISOs have when evaluating application security, as well as a few recommended best practices. We hope these considerations shed light on how security teams think and common asks, allowing you to better plan for them.

Is the app internal or public facing? What does it do?

Let’s start with a couple easy ones. Whether the application is an internal application used by employees or an external application used by the public impacts how you think about security.

The function of the app is also a big factor. A potential attack on an internal timekeeping app has implications that are far less severe than an attack on an external banking app with millions of users. The latter poses much more of an organizational risk than the former and should implement stricter security measures.

Knowing this can help application teams scope out the extent of security features they need to implement to get the application into the hands of users. They can then proactively engage the security team to craft a plan detailing the additional security capabilities they will build and when they intend on building them.

What’s the app’s stack?

You’re not going to write every line of code. If you’ve incorporated other components and modules into the application, open source or not, do you understand what they are, how they’re supported, and potential vulnerabilities? Whether the components are open or closed source, development pipelines can be infiltrated and malicious code deployed. Have you integrated the app with security infrastructure and monitoring tools to detect and alert you of vulnerabilities?

These are important questions to ask as they can shed light on potential vulnerabilities in your software development lifecycle.

Third-Party Threat Management

Integrating third-party components into your app and infrastructure is a common practice. These can be open-source projects or commercial SaaS offerings you have integrated into your stack. While common, doing so has the potential to compromise security.

Here are a couple ways to limit third-party threats in app development

• Open-source validation. When using open-source libraries in app development, it's important to verify that the libraries are up to date and do not contain any known security vulnerabilities. Review the code for vulnerabilities before using it, either manually or using automated tools like those provided by Snyk and others.
• Limit third-party dependencies. Third-party components can expedite development but can also introduce security vulnerabilities. Mitigating those vulnerabilities means limiting the number of third-party dependencies used in the app's development to those you need. You don’t have to write every line of code, but you can’t just use others’ code.

Integration with security infrastructure

In this day and age a security breach is not a matter of if, but when. As a result, integrations with security infrastructure are crucial. These integrations identify vulnerabilities, alert you to adverse events, and mitigate undesirable behavior.

Best practices for integrating app development with security infrastructure include:

• Integrate with observability tools. Observability tools, like those provided by Snyk, Splunk, or New Relic, help engineering teams debug applications. They aggregate and visualize telemetric data, alerting on anomalies, and help you understand why those anomalies occurred.
• SIEM integration. All your logs should be sent to a centralized logging system or SIEM, such as Datadog or ELK. Streaming logs to a centralized system allows for the correlation of that data with other events and alerting to unwanted behavior.
• Leverage consistent authentication and authorization systems. Authentication and authorization secure access to your application. While the former provides secure login, the latter ensures access to protected resources is limited to only those who should have it. Consistent authentication and authorization ensure secure access via predictable schema. When the schema is predictable, deviations are easily detected and can be acted on. Where possible, integrate non-public app access into the authentication and authorization mechanisms used elsewhere in your organization. Where you implement single sign-on infrastructure, you reduce failure points via authentication and authorization handoffs. Coupled with multi-factor authentication and deny by default, a purpose built authorization service can be a strong security countermeasure.

Have secure design practices been implemented?

There are a few tried and tested best practices for application security that you can build into your app from day one. They stem from a zero trust approach and adhere to the principles of least privilege, continuous monitoring, and continuous verification.

• Opt for APIs. Leveraging API functionality is inherently more secure than direct connections. An API call provides access to a telemetry or data feed. Direct connections provide pathways to access other applications or components. Minimizing the blast radius of an attack is key and APIs help accomplish that.
• Segment your Infrastructure. Similar to leveraging API calls, infrastructure segmentation limits connectivity between applications. By isolating application components, lateral movement is hampered which limits the reach of any prospective attacker which, in turn, limits attack blast radius.
• Fail closed and deny by default. The primary way to secure web applications is to fail safe, fail closed, or deny by default. Where the fail open model is permissive with further access, the deny by default model means cutting access when unexpected inputs are delivered or unexpected behavior is taken. That halts vertical and lateral movement in its tracks and enforces the principle of least privilege, a core security concept, where users are provided only the access needed for their job duties.
• Implement defense in depth. Identify ways to mitigate app vulnerabilities and deploy solutions with overlapping functionality, so that there’s no failed handoff or gap between elements of mitigation or security infrastructure.
• Verify prior to access. Following the principle of continuous verification, make sure to always verify prior to providing access. Verify the user’s identity prior to logging them in, and verify they have the right permissions for the action they are trying to take before it can be fulfilled. Do not trust scopes or tokens which can outlive the intended access period.
• Analyze logs. Make sure your application streams all the logs to a single logging system or SIEM. This will let you detect trends and anomalies you could not by reviewing the logs of each system in isolation. It also follows the principle of continuous monitoring.

Will the app contain, process, or manage regulated data (e.g.: PHI, PII, payment card information)?

If your app has highly regulated data, it’s critical to understand what data that is, where it’s stored, and how it’s stored. For example, both HIPAA and GDPR provide enhanced fines in the event data is stored in an unknown location: if you don’t know where the data is, you’re not protecting it. To this end it’s also important to understand where the hosting location is. Are you storing data in an availability zone that opens up compliance to unintended regulatory schema? You cannot effectively secure the data without answering these questions.

Once you answer these questions you can start working with your security team on identifying exactly what measures need to be taken. You’ll need to add data protection and encryption at a minimum. You can also use this opportunity to build data protection guardrails into your application to ensure that regulated data is only available to those with an official need to access it.

Conclusion

There are many security considerations when developing an application. And developers aren’t always aware of them all. After all, they aren’t security professionals. We attempted to shed some light on these considerations, so that you can better understand and plan for them. We also shared a few application security best practices that you can use to ensure your application is as secure as it needs to be now, and in the future.

As always, we’d love to hear your thoughts. Drop us a line, or join our community Slack.