Application Security Architecture Definition
Application security architecture is a unified design that focuses on potential security risks and necessities involved in a specific environment or scenario. It is part of a move toward a shift left approach that makes application security part of the overall design and architecture of an application rather than introducing security later in testing. Application security architecture as an approach also specifies how, where, and when to apply security controls as part of a reproducible design process.
Application Security Architecture FAQs
What is Application Security Architecture?
Modern applications typically have architectural three tiers, each presenting its own potential security risk profile.
Clients live on the top tier or front end of the mobile, web, or internet of things (IoT) application. Since the goal of this tier is smooth interaction, front end developers tend to prioritize a high-quality user experience. There are numerous attacks on this tier, including denial of service and injection attacks.
The application and data from users live on the middle tier of cloud application security architecture where processing takes place behind a protective firewall and other controls.
The bottom tier is where the backend lives, including cloud infrastructure, containers, operating systems, and anything needed to store data or run the application. Most attackers aim to penetrate this tier.
There are several challenges that modern application and network security architectures face. Although the topic of application security is broad and challenges for each organization may differ, here are a few more common issues that implicate and emphasize the need for secure web application architecture.
Inherited Vulnerabilities
Although there is no substitute for careful developers during the coding process, in modern applications some vulnerabilities are inherent. This is because software systems are constantly evolving, updating, and becoming more complex. In the process, it is a constant struggle to prioritize updates, fixes, and maintenance tasks. The result is lasting legacy code in many organizational environments, and risks to security that modern security tools may be less well-equipped to handle.
Third-Party and Open-Source Vulnerabilities
Frequent use of third-party and open source libraries, especially indirect dependencies, has also produced an attractive attack vector. Open source dependencies cause maintainers to accidentally release packages with vulnerabilities or malicious code. While scanning tools are critically important, they cannot catch all such vulnerabilities, and teams should build application security into the architecture by following best practices and enforcing them.
DevSecOps vs Shift Left
Teams should incorporate security throughout the development process by taking a shift left approach rather than DevSecOps which places scanning later in the software development life cycle. The bottleneck that results as development teams scramble for fixes, and triaging issues, results in many false positives and excessive lost time.
Tools for Centralized Management of Application Security Architecture
Application security teams require tools that allows them to constantly monitor and assess the security posture and each aspect of the application’s architecture. The best tools centralize all monitoring and reporting on a single dashboard.
Application Security Architecture OWASP
The Open Web Application Security Project (OWASP) is a nonprofit that releases a yearly list of the top 10 web application security vulnerabilities. These highlights from the 2021 Top 10 Application Security list (the OWASP Top 10 2021) is based on data on the common vulnerabilities and risk profile of more than 500,000 applications.
This list offers some notable insights. One is that broken access control, previously at #5, is now the #1 threat on the list. Another change is that authentication and identification failures fell from #2 to #7. #3 is injection attacks, while #6 is vulnerable and outdated components.
Application security testing orchestration continuously integrates security and the development process as part of the overall cloud security posture. It is essential to include all levels of application security as part of this process, from code via dependencies to configuration in the cloud.
According to OWASP, the age of DevSecOps has forced the art of security architecture into the background in many organizations. The application security field must re-introduce leading security architecture principles to software practitioners and adopt agile security principles to catch up to a modern approach.
Application security architecture is a problem solving approach, not a specific implementation, so there is no single “correct” approach or one solution for architecture. A web application’s specific implementation is likely to be revised continuously throughout its lifetime, although changes to the overall architecture will usually be slow and rare.
The primary aspects of any sound application security architecture include: availability, confidentiality, non-repudiation, processing integrity, and privacy. Each of these application security architecture principles must be innate to all applications.
It is critical to the “shift left” approach to ensure that all security controls are present and functional. Application security architecture and design professionals must stay current with agile techniques, learning to code, adopting developer tools, and collaborating with developers rather than coming to the project months later.
OWASP’s application security architecture patterns, found here, depict a specific context for information usage. Based on application security architecture overview diagrams, these IT security architecture patterns are annotated diagrams with NIST controls catalog references.
Patterns that see repeat use across many IT Security Architectures are called modules—the client and server modules, for example. Since most patterns are divided up this way, they are much simpler to read, understand, build, and maintain.
What is the Application Security Life Cycle?
The application security lifecycle and the software development life cycle (SDLC) run parallel to each other. Traditional security approaches secure an application only late in development or after it is running in production. These development practices are earlier in the modern process, with security incorporated from the beginning of the SDLC into the runtime environment.
According to OWASP, Secure Software Development Lifecycle Requirements include:
- Using a secure software development lifecycle at all stages of development
- Identify threats, facilitate appropriate risk responses, plan for countermeasures, and guide security testing for each sprint planning or design change with threat modeling
- Ensure all user stories and features include functional security constraints
- Verify justification and documentation of all application components, trust boundaries, and significant data flows
- Define application’s high-level architecture and each remote service connected and verify security analysis
- Verify implementation of centralized, reusable, secure, simply designed, and vetted security controls to avoid duplicate, ineffective, missing, or insecure controls.
- Verify security requirements, guidelines, coding checklist, or policy is available to all developers and testers
OWASP also provides Authentication Architectural Requirements:
When proofing identity and designing authentication, all authentication pathways must have the same strength:
- Use of special low-privilege or unique operating system accounts for all application services, components, and servers
- Authenticate all communications between application components, including APIs, data layers, and middleware, with the least necessary privileges enabled
- Use a single, secure, vetted authentication mechanism that can include strong authentication and detect account abuse or breaches
- Verify consistent authentication security control strength all authentication pathways and identity management API implementations
OWASP Access Control Architectural Requirements are as follows:
- Verify the existence and functioning of trusted enforcement points at access control servers, gateways, and serverless functions; never enforce against client
- Access protected data and resources with a single and well-vetted access control mechanism and pass all requests through it to avoid insecure alternative paths or copy-and-paste
- Use roles to allocate permissions, and use attribute or feature-based access control
OWASP’s Input and Output Architectural Requirements are as follows:
- Clearly define how process data should be handled based on content, type and applicable regulations, laws, and policy in the input and output requirements
- Do not use serialization when communicating with untrusted clients, or enforce adequate integrity controls (and encryption if sensitive data is sent) to prevent deserialization attacks
- Enforce input validation on a trusted service layer
- Verify that output encoding is located near the interpreter for whom it is intended
OWASP Cryptographic Architecture Standards indicate:
Design applications with strong cryptographic architecture to protect data assets based on their classification. Strike a balance on what should be designed with cryptographic architecture during architectural or high level design or architectural stages or sprints. Architectural requirements demand consideration throughout the coding phase, and should be reviewed during security architecture and code review.
In addition:
- All keys and passwords should be part of a well-defined process to re-encrypt sensitive data and replaceable.
- Architecture must never offer easy access sensitive data and should treat client-side secrets—such as passwords, symmetric keys, or API tokens—as insecure
OWASP Errors, Logging, and Auditing Architecture:
- Use a common logging approach and format across the system
- Securely transmit logs to a system, ideally a remote system, for detection, analysis, alerting, and escalation
OWASP Data Protection and Privacy Architecture:
Identify and classify all sensitive data into protection levels with associated protection requirements, such as integrity requirements, encryption requirements, privacy and confidentiality requirements, and retention requirements.
OWASP Communications Architecture:
- Encrypt communications between components, especially those in different cloud providers, containers, sites, or systems.
- Verify the authenticity of each side in a communication link (such as TLS certificates and chains) to prevent person-in-the-middle attacks.
OWASP Malicious Software Architecture:
Use a source code control system, accompanying check-ins with tickets for issues or changes and leaving identifiable users and traceability of all changes.
OWASP Business Logic Architecture:
- Define and document all components and their business or security functions
- Verify that high-value business logic flows, including session management, authentication, and access control:
- do not share an unsynchronized state
- are thread safe
- are resistant to time-of-use race conditions and time-of-check
Application Security Architecture Best Practices
Best practices for application data security architecture are numerous. As explained above, they are flexible, but fall within the OWASP guidelines.
Not every practice will apply to every application or organization. However, some of the most common web application security architecture best practices include:
Simplicity. An application security architecture framework must ensure it is simple and fast to develop and deploy secure code. This empowers the development team to focus on rapid development and functionality while ensuring code is secure.
This also demands easy authentication and centralized authorization that ensures all application, service, and other requests are authorized vertically and horizontally without input from developers. The architecture must use a data access framework that renders cracking open an SQL injection vulnerability impossible.
Layered security. Ideally, enterprise application security architecture should plan for failure while ensuring developing code without falling prey to any of the OWASP Top 10 vulnerabilities is a simple matter. Multiple layered security controls should limit the blast radius of failures and prevent catastrophic breaches.
Conduct regular application and data security architecture reviews. Effective application security architecture review takes a three-pronged approach, assessing technologies such as training and process tools; processes such as controls and policies; and people.
Each of these practices should fall in line with the OWASP guidelines.
What is Application Security Architecture Assessment?
The OWASP Architecture Assessment (AA) ensures that application architecture meets all relevant compliance and security requirements, and mitigates against any security threats identified sufficiently.
The Software Assurance Maturity Model (SAMM) was developed in 2009 and the 3-level application security architecture analysis is an important piece of the OWASP SAMM assessment process.
There are several streams in the process: verification, analysis, architecture validation, and architecture mitigation.
Verification. The first stage verifies that the application architecture is meeting all security and compliance requirements and practices it identifies, both ad-hoc and systematically for every system interface. Verification tests the software during development, ensuring they have reached established requirements and acceptable security levels. It usually includes automatic and manual tests, quality analysis, and other evaluation and verification activities.
Architecture analysis. The second stream reviews the architecture for mitigations against typical threats and against specific identified threats from the assessment. The goal of high-level architecture analysis is to ensure that the infrastructure and architecture properly address the identified security requirements to mitigate threats. The security requirements can be raised and listed according to the necessary verification level through the Application Security Verification Standards (ASVS).
Security requirement compliance verification can be conducted ad hoc or systematically per interface. The analysis for all security architecture components must be performed in a structured way. Continuous, ongoing assessment of weakness and possible improvements in the security architecture practices is important to ensuring optimal performance. Mitigation evaluates the effectiveness of security controls continuously, as well as their strategic alignment and scalability.
Architecture validation. These practices facilitate the visualization and analysis of application security architecture. At the lowest level, this involves defining the general perspective of the architecture and listing security mechanisms. The high-level analysis includes organizational architecture revision, compliance with security requirements, testing the efficiency, scalability, and availability of the implemented security controls, and other functions.
Architecture mitigation. Verify whether existing strategies are sufficient to protect structures and components. Review each threat that is identified ad hoc and systematically and record the impact of security decisions and revisions to architecture.
Implementing security processes effectively in the realm of architectural analysis is closely associated with the joint work of architects, designers, developers, and the security team.
Does Avi Offer Application Security Architecture Solutions?
Yes. Traditional web application security solutions such as appliance-based web application firewalls (WAFs) are complex to manage, rigid to scale, lack application security insights, and require costly overprovisioning to compensate for lack of elasticity. These web application security challenges and web application attacks in increasing numbers and severity fuel the need for a modern, secure web application framework.
Modern application development and deployment approaches that include continuous integration and continuous delivery (CI/CD) methods demand elastic capacity and new strategies for distributed application security. A resilient platform with security baked in from the state is the first line of defense against security attacks.
In contrast to traditional hardware-based solutions, Avi’s Web App Security is a comprehensive Web Application and API Protection solution that delivers network and application security with a context-aware web application firewall (WAF) to protect against all forms of digital threats.
Avi’s Web App Security solution offers:
- Positive security with WAF learning mode
- Real-time app security insights
- Centralized application security management
Avi provides real-time visibility, granular insights, and application security analytics in addition to rule matches and traffic monitoring. Avi’s central control plane and distributed data plane create an elastic application services fabric with centralized policies that enables a rapid response as attack surfaces of new applications, microservices or instances are increased.
The Avi WAF is not a perimeter—it is deployed per application based on specific policies to apply for each app. This opens up a world of customization and scalable security that is just not available with traditional tools.
The optimized application security pipeline and stack approach to web application security delivers web-scale performance with point-and-click simplicity. Avi offers ease of use, visibility, and scalability via its integrated application security stack approach. WAF is only the outermost layer.
Learn more about Avi’s application security platform here.