Build a Defense-in-Depth
In reality, there are many more attacks that will be received from the public Internet. Because we are exploring the ATASM process, the list of attacks has been truncated to keep the discussion manageable. Network-based attacks, such as distributed denial of service (DDoS), have not been discussed. However, for a real site, these and many other attacks must be defended, as well.
For example, the networking equipment that routes traffic into the site and between its various layers would all be subject to attack. We have not examined the physical, network architecture. But in a real analysis, we would examine everything from top to bottom. Such an examination would, of course, include the networking equipment, the operating systems of the servers running AppMaker, the database servers, the Java application server, and so on.
Instead, we’ve assumed, for the sake of instruction, that the site is already supported by a trusted and capable administrative and networking staff. That’s a big assumption. As was noted above, due diligence requires that we make no assumptions and always actually confirm or deny practices and technologies.
In order to build a defense-in-depth, an assessment would take into account all of the defenses, including firewalls, intrusion prevention systems, anti-malware software on the servers, network black hole route capabilities (for network and DDoS attacks), and so forth.
As mentioned above, I would divide the architecture into three tiers. I would require network restrictions between each layer, allowing only intended traffic from known hosts/subnets over specific protocols to the intended recipients, and no other traffic, especially inbound from the Internet. I would probably also specify an authentication of the web server(s) to the application server to be validated at communication initialization, so that if the bastion network were lost, an attacker would also have to gain access to the web server in order to send traffic to the application server.
Because the system handles sensitive data from users originating from the untrusted Internet, the Transport Layer Security (TLS), most often implemented as HTTPS, must be used between the user’s browser and the web server, at least for sensitive data transmission. Some architectures would also require TLS (or more properly, communication encryption of some sort) between the web server and the application server, and perhaps even between the application server and the database server? We assumed that the networks in this system are tightly controlled through a mature administrative practice. Therefore, the networks can be considered a trusted infrastructure. Since we’ve separated out three tiers, and there is only a single piece of trusted networking equipment separating each tier (a new assumption and requirement), the store doesn’t feel the need to encrypt the data as it moves between tiers. There are existing protections, and the data are not moving between multiple network segments while passing between tiers.[1] Without this assumption of trust, communications-level encryption would, very likely, be a requirement between tiers, as well.
Furthermore, because secure coding is an art as much as engineering, I would try to get a web application firewall (WAF) placed between the Internet facing network equipment and the web server (or it could go between the web server and the application server, as well). A WAF will detect known and typical attack patterns and prevent these from being passed to the application server and the application server code. Programmers make mistakes; vulnerabilities do escape even the most rigorous secure development lifecycles. It’s a defense-in-depth to anticipate this by removing known attacks, thus protecting those mistakes from being exercised. In addition, most WAF products allow custom rules, so that if a vulnerability is discovered, attacks directed at that specific vulnerability can be removed at the WAF before they can exploit the error during the period of remediation, which can often take some time.
I would assume that at least those controls that have been placed at the Internetfacing edge can and might get compromised. I assume that programming errors will escape into production. Then I design requirements to supplant and enhance the expected controls such that the failure of any single control does not mean the compromise of the entire system, and certainly protect crown jewel data and systems such as identity and financial data with additional, overlapping defenses.
- [1] he PCI standard insists on the encryption of payment information in transit. So, while Ibelieve the architecture as described sufficiently protects the data, compliance with PCI mayrequire encryption between layers. Compliance and security are sometimes not the same thing.
