Security Architecture in Modern Web and Mobile Applications: Principles, Challenges, and Best Practices

Table of Contents:

1- Introduction

2- Security Architecture Approach

3. Network Security: External & Internal Perimeter

4. System & Endpoint Security

5. Application, Identity & Access Security

6. Identity and Access Security

7. Data Security

8. Monitoring and Response, Compliance

9- Conclusion

1- Introduction

Numerous web and mobile applications are regularly developed within large organizations. Employing threat modeling for security architecture assessment can prove beneficial, despite the absence of universally applicable solutions.

Established models often fall short in covering all necessary aspects, and there is skepticism about whether even their creators fully utilize them. Drawing from my practical experience in the field, I favor the adoption of a tailored approach to threat modeling. This preference stems from its dynamic and interactive nature. Security architecture’s primary purpose is to adeptly translate business requirements and security policies into concrete, well-founded measures, all within a structured framework. Essentially, its goal is to safeguard systems against threats through a risk-centric approach, underpinned by coherent and adaptable principles.

Figure 1: The 7 Security Layer (apogeeitservices.com)

2- Security Architecture Approach

A consistent approach to threat modeling is essential for addressing potential threats and vulnerabilities. However, unusual requests from developers or business stakeholders can disrupt this sense of consistency. Therefore, it is advisable to aim for a middle ground, avoiding both high-level abstractions and overly intricate details. Instead, opt for a moderate to low level, striking a balance between the two extremes. In this way, you can view the application holistically as part of your security toolkit, considering potential attack surfaces.

Figure 2: Network Security Logical Architecture (gartner.com)

The approach to security architecture is divided into five abstract layers, namely: Network Security, System or Endpoint Security, Application Security, Identity and Access Security, and Data Security. I recommend implementing security controls for each layer progressively, moving from the outermost to the innermost layer. These controls, when applied across all abstract layers, complement each other in a sequential manner, forming a comprehensive and cohesive secure architecture.

2.1. Assumptions and Prerequisites

To establish a clear scope and framework, it is essential to outline several assumptions and highlight crucial prerequisites before we commence:

2.2. Application-Specific Assumptions:

• We assume that this application operates within a Windows server OS environment and utilizes an MSSQL database.
• The application includes features for uploading files.
• Its user base consists of external users who are not affiliated with the company’s employees or connected to other internal applications or services.
• Unlike web applications primarily accessed via web browsers with minimal frontend code, this mobile app contains a substantial portion of its binary code on external mobile devices. Therefore, it’s imperative to isolate the initial point of contact for the mobile app within the server environment, ensuring it functions as a standalone server. This separation allows for the implementation of mobile-specific security controls and minimizes the risk of a single point of failure (SPoF).
• The operational model revolves around a 3-tiered structure, denoted as “WEB/MOBILE => APP => DB,” with a distinct emphasis on not utilizing WEB/MOBILE as a mere proxy forwarding traffic to internal APP components.
• The APP component operates on a Microsoft IIS server, which can exist as a single server or be divided into public and backend servers. Optionally, an API gateway can be deployed between the WEB/MOBILE and APP components.

2.3. General Security Considerations:

• Security hardware and measures should serve their primary intended purposes within large organizations. For instance, a firewall should not be employed as a Unified Threat Management (UTM), Intrusion Prevention System (IPS), or proxy.

2.4. Network Infrastructure Requirements:

• The network infrastructure should encompass distinct PROD, STAGING, TEST, and DEV, or PROD and NON-PROD environments. Applications within these environments should adhere to identical design principles.

2.5. Environment-Specific Considerations:

• If this application were running within a containerized environment, the architectural and security control configurations might need adjustment accordingly.
• Similarly, if the infrastructure were operating on a Software-Defined Network (SDN), the architectural structure and required security controls could undergo significant transformations.

These assumptions and prerequisites lay the foundation for defining the scope and framework of our endeavor, ensuring that we address the specific needs and constraints of the situation at hand.

3. Network Security: External & Internal Perimeter

Figure 3: G-DATA’s Multi-Layered Security — an intricately advanced information technology security solution (gdata.fr)

3.1. Implement micro-segmentation for all components:

This step is important to effectively prevent any potential lateral movements by malicious actors. Consider applying micro-segmentation to LAN-based components where feasible.

3.2. Enhance the resilience of incoming internet traffic against DDoS attacks and related threats:

Collaborate with your ISP/CDN services to share the network protection responsibilities:

• Use your ISP’s DDoS protection or Intrusion Prevention System (IPS) to filter out a significant portion of malicious traffic.
• Consider deploying an on-premise Application DDoS protection system to counter application-level DDoS attacks.
• Enable CDN traffic cleaning services by announcing your BGP routing, allowing traffic forwarding for sanitization during DDoS incidents.

3.3. Make Web Application Firewalls (WAF):

A mandatory component for all web applications exposed to the internet. These WAFs can be integrated with load balancers or operate as standalone systems, effectively safeguarding against various web-based attacks such as injections and manipulation, provided they are correctly configured.

3.4. Ensure Comprehensive Coverage:

By deploying Intrusion Prevention Systems (IPS), Advanced Persistent Threat (APT) detection tools, anomaly detection mechanisms, or network sandbox solutions across your entire network. Whenever possible, place these tools in inline mode to maximize their effectiveness.

3.5. For applications featuring file upload functionality:

Establish a mandatory protocol for scanning and sanitizing all uploaded files before processing them. This scanning should take place via ICAP protocol, either through load balancers or WAFs, using a file sandboxing tool.

3.6. Encrypt all inter-box connections using well-established and vetted protocols, such as TLS and HTTPS:

Enforce a rule that requires any server requiring internet access to route its connection through a proxy server. For instance, when a mobile server necessitates connecting to Apple or Google notification services, the outgoing connection should traverse a proxy.

3.7. Restrict bi-directional external firewall rules for WEB/MOBILE components, permitting them to initiate connections only:

Exceptions include scenarios like push notifications, where a connection is initiated from the MOBILE server/box for legitimate purposes.

3.8. Recognize the significance of router security and address it as a priority:

Many network backbone infrastructure components operate behind the scenes without the presence of physical firewall barriers.

Consequently, external routers can serve as potential entry points for attackers aiming to infiltrate your network. Prioritize the security and hardening of routers and backbone infrastructure alongside other security components to fortify your network defenses against sophisticated and skilled attackers.

4. System & Endpoint Security

Establish independent and separate Active Directories (AD) for the local networks, treating them as autonomous forests. In the case of LDAP-based traditional domains, avoid creating trust relationships between these forests.

Figure 4: Key Attributes of Endpoint Security (uniserveit.com)

This AD structure is primarily designed for system-level management rather than external-user authentication. If the forests rely on AD federation using the SAML protocol, considerations for trust relationships between forests apply. However, note that many legacy applications and systems do not support SAML.

4.1. The necessitating the use of an LDAP gateway to facilitate communication between distinct AD forests, when required. This LDAP gateway becomes essential when mapping application users to AD-Forest-1, particularly if you intend to manage application-level users within your AD or Identity Management (IDM) system. It is worth mentioning that AD mapping might not be necessary for application-specific users; refer to the ‘Identity and Access Security’ section for further details.

4.2. Implement an independent DNS security tool to filter all DNS requests within the network. This measure helps prevent malicious DNS responses, including tunneling, injections, takeovers, and similar threats.

4.3. Employ application whitelisting mechanisms to restrict the execution of programs exclusively to a predefined set of trusted applications on the servers. This approach ensures that only authorized and known applications can run on the servers.

4.4. Utilize Endpoint Detection and Response (EDR) solutions for tracking malicious behaviors, with a particular focus on activities such as malicious process injections, suspicious memory actions, the use of sophisticated attacker tools, and fileless malware movements.

4.5. Consider implementing Network Access Control (NAC) systems in conjunction with Advanced Persistent Threat (APT) solutions to promptly respond to security threats. NAC can perform compliance checks and ensure servers remain up-to-date with patches and other security software, as mandated by policy.

4.6. Employ File Integrity Monitoring (FIM) tools to monitor and track unintended modifications to critical files and folders on servers, thereby maintaining the integrity of server data.

4.7. Implement Antivirus to conduct continuous scans and removal of malicious files on servers. For added security measures, enable host Intrusion Prevention Systems/Intrusion Detection Systems (IPS/IDS).

4.8. Deploy Data Loss Prevention (DLP) tools to monitor and take proactive measures against inadvertent data movements on the servers, safeguarding sensitive information from unauthorized access or transmission.

5. Application, Identity & Access Security

Step 1: Conduct regular static code analysis, code reviews, and security testing throughout the Software Development Life Cycle (SDLC) for the entire application codebase. Ensure that security controls are integrated into the DevOps process.

Step 2: Prior to deployment, perform penetration testing for the entire application, and repeat this testing whenever significant changes are introduced.

Step 3: Host third-party libraries, extensions, packages, and codes on-premise. Internet-facing pages should source required Javascript, CSS, and other files internally.

Step 4: Before incorporating open-source or third-party libraries into your codebase, access them from a vetted internal repository and conduct routine vulnerability checks, utilizing tools like Nexus, among others.

Step 5: Recognize that client-side security measures can be bypassed. Thus, validate, verify, and double-check all controls on the server-side. Protection against threats like:

• SQL injections.
• Cross-Site Scripting (XSS).
• Cross-Site Request Forgery (CSRF).
• Path Traversals.
• Local File Inclusions.

and more requires a combination of secure development practices, automated vulnerability scanning, security testing, and Web Application Firewalls (WAF), among other measures.

Step 6: In addition to mitigating application-level Distributed Denial of Service (DDoS) attacks, WAF can perform deep packet inspection to identify hidden scripts or manipulations exploiting application vulnerabilities, such as injection and cross-site scripting flaws. The WAF rejects packets containing embedded exploit scripts.

Step 7: Mandatory scanning and sanitization of uploaded files are essential for applications with file upload features. Use a file sandbox tool in conjunction with load balancers or WAFs, employing the ICAP protocol to scan all files before processing.

Step 8: Implement robust session and cookie management alongside security headers.

Step 9: Establish strong web service authentication and session management, relying on robust user-pass credentials, method-based service usage/calls, or token authentication.

Step 10: External user authentication should enforce Two-Factor Authentication (2FA) or Multi-Factor Authentication (MFA).

Step 11: Implement rate limiting or captcha controls for critical functions like login, forms, and file uploads, even for authenticated access.

Step 12: Ensure that web pages adhere to minimum web security standards, including those outlined by the Open Web Application Security Project (OWASP), among others.

Step 13: In mobile application security, apply various controls such as remote wipe, SSL pinning, runtime protection, jailbreaking prevention, and tamper protection. Detailed information on these controls is available in my “Security Tenets for Mobile Applications” post, where you can find comprehensive explanations to avoid redundancy in this article.

6. Identity and Access Security

Figure 5: Identity and access management encompasses a variety of responsibilities and roles. (Tenfold-security.com)

In this network setup, three distinct user identities require management:

6.1. External Users: These include shoppers and merchants who have no association with internal applications or services. Their management is specific to the application itself.

• User administration for this group should occur directly within the application. Passwords should be securely stored in the database using robust hashing algorithms such as SHA256 and SHA3.
• Separate web interfaces should be provided for shoppers and merchants.
• If the need arises to employ Active Directory (AD) or Identity Management (IDM) for user management, it should be conducted through AD-Forest-1, where WEB and MOBILE connect. Application-level users can be linked to AD users using an LDAP gateway. However, this mapping does not be required since these are application-specific users.
• In this topology, both the Web-layer and mobile-layer for these users should reside in the network, where their connections are needed. Consequently, the APP-layer should feature a distinct local authentication-enabled site to accommodate this.

6.2. Internal Users: These users access the ‘Internal WEB box’ and comprise system administrators or business owners who do not engage as consumers of the application. Their management occurs via AD or IDM.

• In this scenario, the WEB dashboard for internal users should be isolated from the WEB and located within the LAN. To facilitate this, the APP-layer should introduce a separate AD-authentication-enabled site with a unique access port, preferably implementing Windows Single Sign-On (SSO).
• Authorization levels for these users, including sys-admins and business owners, should be established. Authorization can be managed through AD groups, IDM role matrices, or the application itself.

6.3. System/Application/Service Users: These users are responsible for maintaining web services, managing database connections, running applications on servers, and some can possess privileged access. Password management for these accounts should be automated using a Password Vault Management (PAM) system.

• System users should not possess local-admin or privileged accounts, and their passwords should be subject to automated changes via the vault or PAM.
• Database connections should utilize Windows SQL authentication, with DB user passwords automatically rotated by the vault or PAM.
• Password changes should also apply to web services, all executed by the vault or PAM.
• Clear-text credentials should never be present in the running application, connection strings, or flat files.

7. Data Security

Beyond HTTPS, application-level encryption should be employed across the entire application to protect data in use on servers and data at rest in the database. Database-level encryption might not be able to secure data from DBAs or sys admins.

• Additional database security measures, such as Database Activity Monitoring (DAM), Database Firewall, Data Masking, and Subsetting for DEV and TEST environments, should be implemented.
• Central Public Key Infrastructure (PKI) management is crucial for certificate and key management.
• Employ File Integrity Monitoring (FIM) tools to track unintended critical file and folder modifications on servers through integrity checks.
• Implement data classification throughout the application’s data flow.
• Utilize Data Loss Prevention (DLP) measures to take preventive actions tailored to application and business requirements.
• Ensure that stored data is encrypted to protect against unauthorized access.

8. Monitoring and Response, Compliance

Security Information and Event Management (SIEM) provides real-time analysis of security alerts and logs from hardware and applications, facilitating compliance reporting.

Figure 6: Examples of the most common regulatory frameworks used in network security (logrhythm.com)

• Security Orchestration, Automation, and Response (SOAR) streamlines incident response activities, collecting inputs from various security technologies and automating necessary actions through playbooks.
• Apply security-hardening practices based on established benchmarks or baselines for all components in the topology.
• Regular vulnerability assessments, apart from penetration testing, are essential to maintain ongoing security.
• Develop comprehensive security policies, standards, procedures; conduct threat modeling, risk assessments, and other related activities to establish a secure enterprise posture.

9- Conclusion

The meticulous examination of the security architecture of a typical web and mobile application reveals a multifaceted landscape characterized by evolving threats, complex vulnerabilities, and the imperative need for comprehensive protection measures. This article has provided a thorough exploration of the various facets of security within this context, addressing aspects ranging from identity and access management to data security, monitoring, and compliance.

We have underscored the importance of adopting a proactive and multifaceted approach to security, emphasizing the critical role of user identity management, access control, and robust authentication mechanisms. Furthermore, we have discussed the significance of safeguarding data throughout its lifecycle, advocating for application-level encryption, access control, and vigilant data loss prevention strategies.

The article has also highlighted the essential role of continuous monitoring, incident response, and compliance adherence in maintaining a robust security posture. We have examined tools and practices such as SIEM and SOAR systems, vulnerability assessments, and security policies that are essential components of a comprehensive security framework.

In a rapidly evolving threat landscape, it is crucial for organizations to remain vigilant and proactive in securing their web and mobile applications. The insights and strategies presented here serve as valuable resources for architects, developers, and security professionals tasked with safeguarding these critical digital assets. By adhering to these principles and embracing the recommended security practices, organizations can bolster their resilience against emerging threats and ensure the long-term integrity, availability, and confidentiality of their web and mobile applications.