App Sec

Overview

Application Security (App Sec) is a very broad topic with many sub-topics. At each step, for every App Sec decision, one must evaluate tradeoffs based on:

• Type of application:
  • Technology stack: The choice of technology stack greatly influences day-to-day Application Security decisions. Higher-level languages (like Python) and their libraries are inherently easier to build with securely. This can reduce App Sec overhead.
  • Third-party dependencies: Third-party dependencies can introduce vulnerabilities. If they’re open-source, they can also become attack vectors.
  • Geography of servers: The location of servers can affect compliance with data protection laws (e.g. GDPR in Europe) and the physical security standards required.
• Scale of application: The size of the user base of the application dictates the scalability of security measures. Large-scale applications may require more robust and automated security solutions. The sophistication of adversaries tends to increase with an application’s scale.
• Type of customers:
  • Sensitivity to breaches of security: Some customers are more sensitive to breaches of security than others. Cultural expectations or compliance strategies can influence a customer’s sensitivity to breaches.
  • Geography of customers: Similar to the geography of servers, the geography of customers also affects compliance with data protection laws (e.g. GDPR in Europe).
• Type of data:
  • Sensitivity of information: Data classification (public, confidential, sensitive) guides the level of protection needed. Sensitive data requires encryption and strict access controls.
  • Size: The volume of data affects storage choices and data protection mechanisms. Large datasets may require more sophisticated encryption and data management strategies. It’s important to note that asymmetric cryptography has a relatively small maximum size that can be encrypted compared to symmetric cryptography.
• Number of employees: More employees requires more internal security perimeters and stronger internal access control mechanisms.
• User experience expectations: There’s a balance to be struck between strong security measures and user convenience.
• Resources available to build: The only way for a system to be 100% secure is for it not to exist. Security is a game of marginal benefits with marginally increasing costs.

Access Control

Access Control is one of the cornerstones of robust Application Security. This critical component ensures that only authorized users can access certain data or functionalities within an application.

Models

Several models exist for managing Access Control for users. Rather than regurgitating that information, this Firewall Times blog post outlines 8 of the most popular Access Control Models.

Authentication vs Authorization

Authentication and Authorization are mechanisms to verify identity and permissions, respectively.

Internal

Internal Access Control is often overlooked at the smallest companies in order to avoid overhead. This decision should be made with abundant caution. As a company grows, Internal Access Control becomes critical. After ~150 developers, it’s inevitable that factions arise. It’s very difficult to maintain a single cohesive social group beyond this point.

The blog post Zero-Trust Security touches on nuances regarding internal employees and access to external user data. It’s a difficult balance to achieve. If data is opaque to internal employees, then it’s impossible to run analytics and Machine Learning on it to gain valuable insights. However, if it’s transparent, then unauthorized access is possible from internal employees. It’s possible to mitigate this with a Two-Man Rule, however, these mechanisms can be bypassed via collusion.

External

External Access Control requires strict reviews to assure that the very large number of threats on the internet cannot penetrate the exposed endpoints of your application.

Threat Model

A critical exercise in understanding the potential attack vectors of an application is Threat Modeling.

Testing

It’s important to test any piece of software and security-vulnerable software is no exception. Here are some resources for testing:

• What is Security Testing?
• Testing in Software Engineering

Patch Management

Complexity breeds vulnerability. An important practice is to regularly maintain software to install the latest versions. This practice needs to be followed for all layers, from third-party dependencies in the application layer to OS updates. Even the OS’s network stack is vulnerable to direct attack.

Conclusion

Security, like any part of software that is not the core application adds overhead. It needs to grow in complexity alongside a project. Take all the guidance here with a grain of salt, especially early in a project to maximize its success.

To be updated with more practical examples upon clearing them.

---

Author

• ← Zero-Trust Security
• Cloud Infrastructure →