This is kind of an atypical post for this blog since I’m trying to keep it as concrete and practical as possible to avoid the potential for uselessness that comes with abstract theorization, but I’m going to put a theory out there about this: http://www.zdnet.com/chinese-hackers-infiltrate-us-government-network-7000031440/#ftag=RSS4d2198e
When combined with other recent IT News events, such as the DOJ’s indictment of the PLA staff believed to be a part of the Mandiant-designated APT1 group, one can detect a simple high-level strategy common to these intrusions. Perhaps the most important observation for a systems engineer working in an enterprise environment is that the method of gaining initial access to the protected networks is typically spear-phishing.
That being known, it’s not surprising to see the Chinese targeting personal information on federal employees with security clearance. That’s exactly the kind of information needed to engage in precise, well-researched, intelligently targeted social engineering efforts to gain control of the accounts owned by federal employees with access to sensitive information.
Now, the first line of defense against such attacks lies outside the scope of the system engineer’s duties. Staff members on the front lines, such as help desk staff who may be responsible for changing user passwords at request, need to be well-educated in these matters, and they need to keep vigilant watch. Additionally, strict adherence to proper protocol for password resets combined with multi-factor authentication of individuals calling to have their passwords reset (for example) would go a long way to mitigate the risk of acquiring those credentials via social engineering efforts.
But in our domain, which does not extend to cover the vigilance of the help desk staff or their protocol, we must take this information to mean that we need to reduce trust for our protected local networks as far as possible. These APT actors are gaining access to these protected networks through means outside of the controls available to system engineers, for they are exploiting vulnerable people rather than vulnerable systems. Once access has been gained to the network, these APT actors tend to move laterally by exploiting vulnerabilities in poorly secured systems which have heretofore relied upon the impenetrability of the network for security.
And now they’re in our field.
Lots of talk of the death of “traditional security measures” and the need for a shift in focus from those to incident response flies around the Interwebs, but it seems misguided to me. Do we need excellent incident response? Yes, but obviously not at the cost of basic security practices which remain crucial to our infrastructure. A very high percentage of attacks can be blocked entirely or mitigated significantly through basic security practices. The sad fact is that these practices’ absence or inadequacy is probably one of, if not the most, significant enablers of APT actions.
Ask any penetration tester for his greatest obstacles in exploiting systems and you’ll likely receive a list of basic security practices. A properly locked-down system with excellent mandatory access control will stymie even zero-day exploitation of software vulnerabilities.
So get on it, system engineers. Ours is a difficult task, for the level of understanding required to restrict the behavior of software systems is very deep. Only through thorough comprehension of the behavior expected of software systems can one design limits on that behavior which contain but do not impede the software. This is where we need to focus our efforts, for even if foreign nation-states’ hackers gain access to our systems, we should be able to prevent them from exercising more control over the system than the compromised credentials need to permit (being properly restricted, themselves, to the level of access absolutely essential to the duties of the corresponding staff member).
With these measures in place, detecting and responding to the incidents which do occur will be made much easier.
From a high level, this stuff is typically easy to understand and fairly obvious. For the sake of discussion (but by no means an exhaustive or comprehensive one, at that; it’s a blog, give me a break), off the top of my head:
- Simplify the system as much as possible, leaving only essential services in operation.
- Reduce the attack surface to only that absolutely required by the essential services.
- Keep the system’s software (including both the operating system and the applications) up to date.
- Monitor the system’s software for any modifications made outside of the controlled system administration processes.
- Contain the system’s software with a mandatory access control system.
- Enforce strong authentication and authorization policies to control access to the services.
- Thoroughly audit the system to allow for rigorous monitoring and incident response.
- Bonus: Monitor the system’s communications for anything out of the ordinary.
As I said earlier, if you accomplish these elementary security practices, it will be extraordinarily difficult for an attacker to compromise your system. I have worked with penetration testers and security experts whose jobs are focused on attacking systems and exploiting vulnerability. If you’ve been there, you know the modus operandi consists of absolutely nothing magical or incomprehensible. The goal of the attacker is to locate vulnerability and exploit it to control the system. The vulnerabilities tend to be related to:
- Code Vulnerability
- Example: Exploiting new or known vulnerabilities against patched (rare) or unpatched (common) software.
- System Integrity
- Example: Compromising core utilities or programming with attacker-provided code
- Unauthorized Access (especially of system administration accounts)
- Example: Spear-phishing campaigns aimed at the acquisition of user credentials
- Violation of User Security Policy
- Example: An attacker leveraging a user’s security context against the regulations and/or guidelines imposed upon that user’s use of his or her powers.
- User Accounting
- Example: An attacker remains successfully hidden on a system due to insufficient auditing and monitoring.
If you’ll notice, you can map the major concerns to the six elements described above:
- Code Vulnerability is reduced primarily by steps 1-3.
- System Integrity is upheld primarily by step 4.
- Unauthorized Access is prevented primarily by steps 5 and 6.
- Violation of User Security Policy is limited primarily by steps 5 and 6.
- User Accounting is achieved by step 7.
Given the spear-phishing concern, it is worth pointing out that the least controllable factor in security is a powerful user’s misbehavior, but if you’re securing your own systems for your own uses, this is unlikely to be much of an issue for you (I hope).
So despite the alarmism which seems to be the constant timbre of the Interwebs, let us move forward with the belief that we can defend ourselves with righteousness. It’s always easier to be the attacking party than the defending party, for the latter requires perfection all around, while the former requires only competent exploitation of any discoverable vulnerabilities (as a result of error or unavoidable circumstance) on behalf of the defending party.
A black hat is easy to wear, but a blue hat requires more perfect coordination and understanding for which all should strive.