The Security Architecture of a Typical Web and Mobile Application

Many web and mobile applications are developed routinely in large organisations. You can benefit from some threat modelling for security architecture assessment, even though they are not one-size-fits-all solutions. The known models do not tick all the boxes. It is doubtful that even those who created these models use them thoroughly.

From my field experience, I prefer to follow a custom threat modelling due to its being a dynamic and interactive process. Because security architecture is to securely transform business needs and security policy into concrete and sound measures in a structured way. In other words, it is to secure systems against threats in a risk-based approach based on coherent and flexible principles. In this context, the outline of this post is as follows:

• THREAT MODELLING APPROACH
• ASSUMPTIONS AND PRE-CONDITIONS
• NETWORK SECURITY: EXTERNAL & INTERNAL PERIMETER
• SYSTEM & ENDPOINT SECURITY
• APPLICATION, IDENTITY & ACCESS SECURITY
  • WEB AND MOBILE APPLICATION SECURITY
  • IDENTITY AND ACCESS SECURITY
• DATA SECURITY
• MONITORING AND RESPONSE, COMPLIANCE
• CONCLUSION

THREAT MODELLING APPROACH

Threat modelling should be a repeatable process to address threats and possible weaknesses. However, a weird demand coming from your developers or business owners can suddenly change your ‘repeatability’. So, if possible, you should try to stay at neither a high level nor an elaborate level. On the contrary, you should stay at a moderate/low level between high and elaborate levels. Then, you should approach the application as a whole within your security arsenal by minding the possible attack surfaces.

I define my practical approach to the security architecture in five abstract layers respectively: Network Security > System or Endpoint Security > Application Security > Identity and Access Security > Data Security. I propose controls for each layer each time until I advance to the innermost layer. The determined controls for all abstract layers complement each other consecutively and collectively present an entire secure architecture picture.

ASSUMPTIONS AND PRE-CONDITIONS

Before starting, we need to make a few assumptions and underline the important pre-conditions to properly define our scope and framework:

• The application-spesific matters are given below:
  • I assume this app runs on Windows server OS environment, and it has MSSQL database.
  • It has file upload options as well.
  • It serves external users who are not employees of the company. The users of this app are not tied with or related to other internal applications or services.
  • Unlike a web application that is reached out from the browser with minimal frontend code, the mobile app has a significant part of your app as binary in someone else’s mobile devices. So, the mobile app’s first contact server in your environment should be separated as a standalone server. Hence, you can apply some mobile-specific security controls and mitigate the single point of failure (SPoF) risk.
  • A 3-tiered “WEB/MOBILE => APP => DB” structure is the key operating model.
  • WEB/MOBILE should not be used as a Proxy that only passes traffic to its internal APP.
  • APP runs on Microsoft IIS server, and it can be one server or split into two servers as public and backend. API gateway is optional between WEB/MOBILE and APP components.
• Security hardware and measures should only serve their main purpose in large organisations. For example, a firewall should not be treated as UTM, IPS or proxy as well.
• A network infrastructure should have separate PROD, STAGING, TEST and DEV, or PROD and NON-PROD environments, and applications in these environments should have an identical design.
• If this application had been running in a container environment, the architecture and security controls to be implemented could have changed accordingly.
• If this infrastructure had been running on a SDN network, the architecture and security controls to be implemented could have changed completely.

NETWORK SECURITY: EXTERNAL & INTERNAL PERIMETER

• All DMZ-located components should be in micro-segmentation so that preventing any malicious lateral movements. LAN-located components should also be in micro-segmentation, if possible.
• All incoming traffic from the internet should be as clear as possible against DDoS, etc. So, some of the network protection burdens can be shared with your ISP/CDN services.
  • ISP’s DDoS protection or IPS service can clear most malicious traffic. You may also need an on-premise Application DDoS protector against application-level DDoS attacks.
  • CDN traffic cleaning services can help you at the time of DDOS by your BGP announcing that enabling traffic forwarding for sanitization.
• WAF should be mandatory for all internet-faced web applications. It can be mounted on a load-balancer or standalone. It can prevent against most web attacks like injections, manipulation and so on if it is properly configured.
• IPS, APT, anomaly detection tool or network sandbox tools should encompass the entire network and be placed inline mode if possible.
• If the application has a file upload feature, it is mandatory to scan and sanitize the uploaded files before processing them. So, over LB or WAF via ICAP protocol, all files must be scanned by a file sandbox tool.
• All connections between boxes should be encrypted with well-known vetted protocols (TLS, HTTPS, etc.).
• If any server needs to access the internet, the connection should be gone over a Proxy. For example, if the mobile server needs a notification service to Apple or Google, the outgoing connection should pass through a Proxy.
• There should not be a bi-directional external firewall rule for the WEB/MOBILE unless it initiates a connection. For example, maybe for a push notification purpose, there can be a connection that is initiated from MOBILE server/box.
• The router security should not be overlooked and it should also be tackled. Most network backbone infrastructure components are connected behind the curtains without a physical firewall broker or alike. So, the external router can be used to circumvent firewalled networks and an easy gate to the innermost switches in your LAN. Therefore, sophisticated and skilled attackers preferably select routers to infiltrate networks. In other words, besides security components, you should focus on router and backbone security and their hardening as well.

SYSTEM & ENDPOINT SECURITY

• Active directories for DMZ and local networks should be separated as an independent forest. There should not be any trust-relationship between them if they are LDAP-based traditional domains.
  • This AD structure is for system-level management, not for external-user authentication. If these forests are AD federation that relies on SAML protocol, then you may talk about a trust-relationship between forests. However, most legacy applications and systems do not support SAML. Then, the LDAP gateway comes to communicate two different AD forest, if necessary.
  • If you want to map application user to your AD-Forest-1 on DMZ, you still need an out-of-box LDAP gateway. This is because, you would like to manage your application-level users with your AD or IDM. Actually, there is still no need any AD mapping because they will be app-spesific users.
  • Please refer to the following ‘Identity and Access Security’ title for the more details.
• All DNS requests in the network should be filtered by an independent DNS security tool to prevent malicious DNS responses like tunnelling, injections, takeovers, etc.
• Application whitelisting measures should be used for limiting the programs that can be executed on this application’s servers. It helps to process only a set of trusted applications on servers.
• EDR is for malicious behaviour tracking. Especially it should be used for malicious process injections, suspicious memory actions, sophisticated attacker tools, fileless malware movements and so on.
• NAC can be used with APT systems collaboratively to take immediate action. It can do compliance checks. It can keep servers up-to-date with the patches along with any other security software dictated by policy to be present on the servers.
• FIM tool is vital for tracking unintended critical file/folder modifications on servers via integrity check.
• Antivirus or antimalware tools help to continuously scan and clean malicious files on servers. For additional controls, host IPS/IDS should be enabled as well.
• DLP tools can help to monitor and take action against unintended data movements on the servers.

APPLICATION, IDENTITY & ACCESS SECURITY

WEB AND MOBILE APPLICATION SECURITY

• The entire application code base should be regularly subjected to static code analysis/review and security testing throughout the SDLC. Also, security controls should be followed through the devops process.
• Before going to production, penetration testing should be conducted for the entire app. Any major change requires repeating penetration testing.
• The 3rd party libraries, extensions, packages and codes, should be hosted on-premise. The internet-faced pages should invoke required Javascript, CSS and other files from inside.
• Before using or embedding any open-source or 3rd party libraries into your code base, all of them should be used from an internal vetted repository alongside regular vulnerability checks, like Nexus, etc.
• Client-side measures can always be circumvented. So, all controls should be validated, verified and rechecked at the server-side. Measures against SQL injections, XSS, CSRF, path traversals, local file inclusions and so on can only be resisted together with secure development, automated vulnerability scanning and security testing, WAF, etc.
• Besides application-DDOS, WAF can perform deep packet inspection seeking hidden scripts or manipulations that can exploit application vulnerabilities such as injection and cross-site scripting flaws. The WAF rejects any packets incorporating embedded exploit scripts.
• If the application has a file upload feature, it is mandatory to scan and sanitize the uploaded files before processing them. So, over LB or WAF via ICAP protocol, all files must be scanned by a file sandbox tool.
• A strong session & cookie management alongside security headers should be handled carefully.
• A strong web service authentication and its session management is needed. It should rely on strong user-pass credentials with method-based service usage/calls or a token authentication.
• External user authentication should rely on 2FA/MFA.
• For critical functions like login, forms, file upload, etc there should be rate-limiting or captcha controls, even after an authenticated access.
• Web pages must meet minimum web security standards consisting of OWASP, etc. 
• For mobile application security, several mobile security controls can be applied such as remote wipe, SSL pinning, runtime protection, jailbreaking control, tamper protection and so on. I already mentioned all these controls in detail in my “Security Tenets for Mobile Applications” post. So, I invite you to read that post because I would not make this article longer by repeating the same things here.

IDENTITY AND ACCESS SECURITY

In this topology, there are 3 identities/users you need to handle:

• External users: They (shoppers and merchants) are not involved with other internal apps or services. They should be managed ad-hoc on the application level.
  • User management should be handled on the application in ad-hoc. Their passwords will be stored in DB by using hashing algorithms such as SHA256 and SHA3.
  • These users are shoppers and merchants, and there should be two web interface for each of them.
  • If there is a need to use AD/IDM for user management, it should be done with AD-Forest-1 on DMZ which WEB and MOBILE connects to, and then the application-level created users are mapped to AD users by using an LDAP gateway. Actually, there is still no need any AD mapping because they will be app-spesific users.
  • In the topology, these users’ Web-layer and mobile-layer should be located in DMZ where they are required to connect. And for this, the APP-layer should have a regarding separate local-authentication enabled site.
• Internal users: forthe ‘Internal WEB box’ access. They are only system admins or business owners. They are not the consumer of the application. They manage the application itself by accessing ‘Internal WEB box’ in the topology. They should be managed by AD or IDM.
  • In the topology, these users’ WEB dashboard should be separated from DMZ WEB and located in LAN. And for this, the APP-layer should have a separate AD-authentication enabled site with a different access port. Preferably, Windows SSO.
  • There should be authorization levels for these users as sys-admins and business owners. So, they have separate tasks to do. Authorization can be handled with AD groups, IDM role matrices or via the application itself.
• System/application/service users: They are required to maintain web services and database connections, running of applications on servers, etc. Some of them can be privileged. And all of these account passwords should be managed automatically by a Password Vault Management or a PAM.
  • System users should not be local-admin or any privileged accounts. Their passwords should be automatically changed by the vault or pam.
  • DB connection should be made with Windows SQL authentication. And DB user password should be automatically changed by the vault or pam.
  • Web services passwords should be automatically changed by the vault or pam.
  • In the running application or any connection strings or in flat-file, there should be any clear-text credentials.

DATA SECURITY

• HTTPS connection requirements aside, application-level encryption should be implemented throughout the entire application to protect data-in-use in servers and data-at-rest in the database. If the database supports database-level encryption, it will not protect the data from DBA or sys admins! So, the application-level encryption is very useful than other solutions.
• Moreover, additional database security measures like below should be implemented:.
  • DAM (database activity monitoring) for monitoring and analyzing all database activity.
  • Database Firewall to prevent internal and external attacks from reaching the database.
  • Data masking and subsetting for DEV and TEST environments.
• A  central PKI management is vital for certificate management, and key management for encryptions.
• FIM tool is also vital for tracking unintended critical file/folder modifications on servers via integrity check.
• Data classification is needed through data flow in the entire application.
• DLP can also help to take preventative action according to application and business needs.
• The data put on storage should also be encrypted against prying eyes.

MONITORING AND RESPONSE, COMPLIANCE

• SIEM is to provide real-time analysis of security alerts and logs coming from hardware and applications; it also logs security data and generates reports for compliance purposes.
• SOAR is to collect inputs monitored by the security operations team. For example, alerts from the SIEM system and other security technologies to help define, prioritize and drive standardized incident response activities. By playbooks, it can proceed with necessary actions automatically as well.
• Security hardening activities for all components in the topology are required based on vetted benchmarks or baselines.
• Except penetration testing, a regular vulnerability assessment is required to sustain continuous security.
• Security policies, standards, procedures, threat modelling, risk assessment, and all other inclusive activities are also necessary to build a secure posture for the enterprise.

CONCLUSION

In this post, I do not talk about cloud based app, microservices etc. Meanwhile, most principles given above can be generalized to all type architectures. The design can always change but the main principles remain. This post, of course, does not cover all topics in the security architecture. However, it tries to draw a far-reaching framework.

The featured photo above is the facade of the Alexander Sarcophagus in the Istanbul Archaeology Museum