If the NSA cannot completely secure their network, then what hope does your average network administrator have with a fraction of the budget and manpower? Are those firewall rules, password policies, and security updates just pissing into the wind?
Hopefully not, but it is interesting to consider a security design around the premise that your systems are compromised, that each user is or could be malicious, and that your network is as open as the wi-fi at Starbucks.
With that as a starting point, you can already see how decisions around security would be changed. No longer can you solely rely on perimeter firewalls and network intrusion detection systems to secure internal servers.
How could we cope with such a scenario? Here are some ideas which could help limit the impact of operating in a world where networks and users are easily compromised -
- Encryption: Of course, we all use VPNs to encrypt external connections to our network, but start encrypting internal traffic on your network as well, whether it be utilizing higher level protocols such as SSL/TLS or IPsec at the network layer. In addition to encrypting data on the wire, encrypt sensitive data stored on drives or in databases. Of course, all of this requires having a robust PKI with a well thought out system to store and manage private keys.
- Host-based Intrusion Detection Systems (HIDS): Your network IDS may provide some value, but once an attacker, virus, or worm is on your internal network it may not be much help. Consider using HIDS to secure individual servers from internal attacks and detect unauthorized changes to the system before damage is one. They can monitor system files to compare against known good checksums and monitor logs for unauthorized activity.
A good open-source HIDS worth looking in to is OSSEC.
- Compartmentalize Access: In order to limit the damage from compromised hosts, software, or accounts, give each user the most limited access they need to perform their role. This means that roles first need to be defined, and that the services through which data is accessed need to have access controls available. This is a difficult task to perform though, especially when you have to weigh the value of sharing information across roles or departmental boundaries.
Furthermore, service accounts and accounts used by IT staff should also be limited. Take a long hard look at who has Domain Admin or root access. Make sure each service runs under a dedicated account that has the least amount of privileges to run. No, Microsoft SQL Server does not require local admin privileges (let alone Domain Admin rights).
Finally, do not discount the value of passing the buck on to a service provider who may have more experience and resources in securing a particular type of service. When evaluating SaaS providers though, still perform your due diligence by requesting and reviewing SAS70 audit reports, or the verifying provider's adherence to various third-party compliance measures. Then rely on the underpinning contract with the provider to enforce these standards.
When the NSA says complete security can't exist, we should stop and listen. While I am certainly not advocating throwing away your firewall, consider designing your security policies and standards as though your trusted network isn't so trusted.