From the perspective of someone who is charged with assessing security, security principles and best practices provide value in their application as well as insight into how and where security might be weak. To use an analogy, who would better know how to destroy a bridge than the engineer who designed the mechanics that make it strong? By understanding what makes security strong, you can, by deduction, predict where security is most vulnerable. Cryptography is a good example. Have you ever seen a movie where the would-be thieves break into a computer system by cracking 128-bit 3DES? In reality, 3DES, when properly implemented, is quite strong; consequently, attempting to crack the algorithm would not likely be the best way to break into the network. At the same time, you rarely see a computer system broken into because of a cross-site scripting or SQL injection attack in the movies. When you read this chapter, think about how applying this principle could improve security, but also think about how the absence of this principle could be used to compromise your organization’s security.
At its most basic level, security is easy—unfortunately, networks rarely exist at their most basic level. That said, you can make security as difficult as you want to, but one of the most effective security maxims is this: keep it simple. The more complex you make security, the more difficult security will be—both to secure the system and to assess the effectiveness of the security. This is true whether you’re designing a Web application or deploying a new server. Simple is good. How do you keep it simple? One way is to break security down to discrete objectives:
Keep services running and information away from attackers.
Allow the right users access to the right information.
Defend every layer as if it were the last layer of defense.
Keep a record of attempts to access information.
Compartmentalize and isolate resources as much as possible.
Don’t make the same mistakes that everyone else makes.
Don’t let the aforementioned objectives cost too much.
This is what it is all about, right? Keeping the bad guys out and services available. The place to start building security is to deny everyone access and design appropriately robust systems and applications. Deny access by default; the Everyone: Deny rule is the security professional’s best friend. Similarly, when conducting penetration tests, an area to target is systems that allow access by default—for example, if a server is running Microsoft Windows 2000 Server, the default file system and shares permission is Everyone: Full Control.
Because you’ve denied access by default, you will need to give authorized users and administrators the ability to access the information they need—but only at the level they need it. In the security realm this is called least privilege. Users and administrators should have access to information assets only to the extent necessary to accomplish their job duties—beyond that, any access possessed by users or administrators is an unnecessary risk. Similarly, applications and services should only operate under the minimum privileges needed to run.
Computer networks have evolved from isolated bus networks that serve a single location to fully interconnected networks spanning the globe, but security has not kept pace. For example, consider the failure of the firewall to evolve. Many networks still rely on a firewall as the single layer of protection for the information hosted on the network, much as an eggshell protects an egg. Once an eggshell is broken, it can do little if anything to protect its contents; similarly, once a firewall has been compromised, it can do little if anything to protect the information within the firewall.
Primarily a defense against outsiders, most firewalls do little to protect against an attack on resources on the intranet that originates locally. Relying on a single layer of protection is an all-around losing proposition. Every layer should be protected as if it were the last layer of defense between the attacker and the information. Becoming skilled at penetration testing will greatly improve your ability to build better in-depth defense strategies for your organization’s network. Most successful compromises are actually several smaller compromises in succession; therefore, preventing smaller compromises through in-depth defense strategies is much better protection for the network against both known and unknown attack sequences.
Tip
I refer to in-depth defense as "network security fault tolerance." While some network administrators and IT managers might not fully understand security threats, most do understand fault tolerance and, furthermore, would never dream of deploying a mission-critical application on a server without some type of RAID array for data protection and reliability.
When it comes to audit logs, the worst time to realize you need them is when you need them. Too often, the first time network administrators think of what type of auditing they need to have enabled is after a successful attack has occurred. Deciding what events to track and how long to keep the audit log files is not a simple task. You must take into account several factors, such as performance impact and log size. Enabling auditing is the easy part—reviewing the logs is decidedly more complex. Separating innocuous events from those that might indicate an attack requires a fair degree of experience reading log files and a solid knowledge of how attacks are carried out. By becoming a skilled penetration tester, you’ll learn how attackers attempt to cover their tracks and prevent their presence from being discovered; you’ll also increase your ability to find attack footprints in audit logs.
Shipbuilders have learned to successfully compartmentalize bulkheads and keels for ships; this innovation prevents a single hole in the ship’s outer shell from sinking the entire ship. Network security can greatly benefit from this type of compartmentalization through application of the following techniques:
Simplify network architecture. Small networks are easier to manage than large ones, and segregating networks into infrastructure components divides large networks into smaller ones. By creating compartments, you minimize the entanglement of network communication pathways and the resulting Swiss cheese effect on firewall rules and router access control lists (ACLs).
Create a choke point to isolate and contain a network compromise. Creating a "choke point" enables you to independently disconnect parts of the network should they become compromised or infected by a virus. Temporarily halting the business for a single compartment by disconnecting it from other network compartments is likely a pale comparison to the cost of recovering computers infected with a worm virus (think Nimda).
Isolate zones of different trust levels. Perhaps the biggest benefit of compartmentalizing is that you can segment and isolate servers and workstations that have different levels of trust. For example, you can create separate networks for your organization’s human resources information, which has restricted access even among administrators, and your organization’s Web servers. A good place to start designing a fully compartmentalized network is by creating distinct levels of trust corresponding to minimum security measures. For example, you might create a zone with security controls that comply with some type of legislation, such as HIPAA (Health Insurance Portability and Accountability Act of 1996) or GLB (Gramm-Leach-Bliley Act), another zone for domain controllers, and one zone each for user and administrator workstations.
One time-honored penetration testing strategy is to attempt to compromise hosts that typically have lower trust levels, and then use these hosts as a staging platform to attack hosts or networks that have higher levels of trust.
Take it as free advice: look at the mistakes that lead to security compromises for others, and don’t do what they did. It sounds almost too simple, but this lesson is worth learning.
Common mistakes are just that—common; with forethought, however, they do not have to be your mistakes. When assessing security, always look for common mistakes. Read media accounts of computer crime and security incidents and over time you’ll notice the same vulnerabilities exploited. Don’t fall into the trap of making these mistakes.
There’s always a catch, isn’t there? Everyone is for security (and reliability, high performance, and privacy, too) until they see the bill. In the end, as my microeconomics professor at the University of Colorado was fond of saying, quoting Robert Heinlein, "There ain’t no such thing as a free lunch." Security is about risk management, and a central part of risk management is spending your limited resources on security well or, in layman’s terms, "getting the most bang for your buck." You can lower the cost of securing applications and networks by designing them from the start with security in mind. In addition, you will be more likely to obtain organizational support when you can connect security with cost savings.
The first principle of security is that no network is completely secure—information security is really about risk management. In the most basic terms, the more important the asset is and the more it is exposed to security threats, the more resources you should put into securing it. Thus, you must be able to evaluate an asset’s value, the threats to an asset, and the appropriate security measures.
Without training, administrators too often respond to a security threat in one of three ways:
Ignore the threat, or acknowledge it but do nothing to prevent it from occurring.
Address the threat in an ad hoc fashion.
Attempt to secure all assets to the utmost degree, without regard for usability or manageability.
None of these strategies takes into account what the actual risk is, and all of them will almost certainly lead to failure.
Managing security risks can be an incredibly daunting task, especially if you fail to do so in an organized and well-planned manner. Risk management often requires experience with financial accounting and budgeting, as well as the input of business analysts. Building a risk assessment of an organization’s security can take months and generally involves many people from many parts of the company. You can use the following simple process outline for assessing and managing risk:
If you try to assess and manage all security risks in your organization, you are likely to be overwhelmed and certain to miss critical details. Before beginning a risk assessment, set the scope of the risk assessment project. For example, you might want to limit the project to a certain service or business unit. This helps you to better estimate the time and cost required to assess the security risks in the project and to more easily document and track the results.
The second step in assessing risk is to identify assets and determine their value. When determining an asset’s value, take these three factors into account:
The financial impact of the asset’s compromise or loss
The nonfinancial impact of the asset’s compromise or loss
The value of the asset to your competitors
The financial impact of an asset’s compromise or loss includes revenue and productivity lost because of downtime, costs associated with recovering services, and direct equipment losses. The nonfinancial impact of an asset’s compromise or loss includes resources used to shape public perception of a security incident, such as advertising campaigns, and loss of public trust or confidence. The value of the asset to your organization should be the main factor in determining how you secure the resource. If you do not adequately understand your assets and their value, you might end up securing the lunch menu in the cafeteria as stringently as you secure your organization’s trade secrets.
The process of predicting threats and vulnerabilities to assets is known as threat modeling. Through the exercise of threat modeling, you are likely to discover threats and vulnerabilities that you did not know about or had overlooked, and you should document the better known threats and vulnerabilities. You can then mitigate risk rather than having to react to an actual security incident. By building your skills as a penetration tester, you will find that your ability to model threats is greatly improved, and vice versa.
After completing the threat model, it is essential that you document the security risks so that they can be reviewed and addressed systematically. When documenting the risks, you might want to rank them. You can rank risks either quantitatively or qualitatively.
Quantitative rankings use actual and estimated financial data about the assets to assess the severity of the risks. For example, you might determine that a single incident of a security risk will cost your organization $20,000 in financial losses while another will cost the organization only $5,000.
Qualitative rankings use a system to assess the relative impact of the risks. For example, a common qualitative system is to rank the product of the probability of the risk occurring and the value of the asset on a 10-point scale. Neither quantitative nor qualitative risk assessment is superior to the other; rather, they complement each other. Quantitative ranking often requires acute accounting skills, while qualitative ranking often requires acute technical skills.
After completing the risk assessment, you must determine what general risk management strategy to pursue and what security measures you will implement in support of the risk management strategy. The result of this step is a risk management plan. The risk management plan should clearly state the risks, threats, and possible effects on the organization, risk management strategy, and security measures that will be taken. As a security administrator, you will likely be responsible for or involved in implementing the security measures in the risk management plan.
Once the actions defined in the risk management plan are implemented, you will need to monitor the assets for realization of the security risks. The realization of a security risk is called a security incident. You need to trigger actions defined in contingency plans and start investigating every security incident as soon as possible to limit the damage to your organization.
As time progresses, changes to your organization’s hardware, software, personnel, and business processes will add and eliminate security risks. Similarly, threats to assets and vulnerabilities will evolve and increase in sophistication. You need to track these changes and update the risk management plan and associated security measures regularly.
Once you identify an asset and the threats to it, you can begin determining what security measures to implement. The first step is to decide on the appropriate risk management strategy. The rest of this section will examine the four general categories of risk management that you can pursue:
Acceptance
Mitigation
Transference
Avoidance
By taking no proactive measures, you accept the full exposure and consequences of the security threats to an asset. Accepting risk is an extreme reaction to a threat. You should accept risk only as a last resort when no other reasonable alternatives exist, or when the costs associated with mitigating or transferring the risk are prohibitive or unreasonable. When accepting risk, it is always a good idea to create a contingency plan. A contingency plan details a set of actions that will be taken after the risk is realized and will lessen the impact of the compromise or loss of the asset.
The most common method of securing computers and networks is to mitigate security risks. By taking proactive measures to either reduce an asset’s exposure to threats or reduce the organization’s dependency on the asset, you are mitigating the security risk. Generally, reducing an organization’s dependency on an asset is beyond the scope of a security administrator’s control; however, the former is the primary job function of a security administrator.
One of the simplest examples of mitigating a security risk is installing antivirus software. By installing and maintaining antivirus software, you greatly reduce a computer’s exposure to computer viruses, worms, and Trojan horses. Installing and maintaining antivirus software does not eliminate the possibility of a computer being infected with a virus because inevitably there will be new viruses that the antivirus software cannot protect the computer against. Thus, when a risk is mitigated, you still should create a contingency plan to follow if the risk is realized.
When deciding to mitigate risk, one of the key financial metrics to consider is how much your organization will save because of mitigating the risk, minus the cost of implementing the security measure. If the result is a positive number and no other prohibitive factors exist, such as major conflicts with business operations, implementing the security measure is generally a good idea. On occasion, the cost of implementing the security measure will exceed the amount of money saved, but the measure is still worthwhile—for example, when human life is at risk.
An increasingly common and important method of addressing security risks is to transfer some of the risk to a third party. You can transfer a security risk to another party to take advantage of economies of scale, such as insurance, or to take advantage of another organization’s expertise and services, such as a Web hosting service. With insurance, you pay a relatively small fee to recuperate or lessen financial losses if the security risk should occur. This is especially important when the financial consequences of your security risk are abnormally large, such as making your organization vulnerable to class action lawsuits.
When contracting a company to host your organization’s website, you stand to gain sophisticated Web security services and a highly trained, Websavvy staff that your organization might not have afforded otherwise. When you engage in this type of risk transference, the details of the arrangement should be clearly stated in a contract known as a service level agreement (SLA). Always have your organization’s legal staff thoroughly investigate all third parties and contracts when transferring risk.
The opposite of accepting a risk is avoiding it entirely. To avoid risk, you must remove the source of the threat, exposure to the threat, or your organization’s reliance on the asset. Generally, you avoid risk when there is little to no possibility of mitigating or transferring the risk, or when the consequences of realizing the risk far outweigh the benefits gained from undertaking the risk. For example, a law enforcement agency might want to create a database of known informants that officers can access through the Internet. A successful compromise of the database could result in lives being lost. Thus, even though many ways to secure access to the database exist, there is zero tolerance of a security compromise. Therefore, risk must be avoided by not placing the database on the Internet or perhaps not storing the information electronically at all.
In 2000, Scott Culp of the Microsoft Security Response Center published the article "The Ten Immutable Laws of Security" on the Microsoft website, which you can read at http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx. Despite the fact that the Internet and computer security are changing at a staggering rate, these laws remain true. As a penetration tester, the laws provide a good roadmap of areas that you need to assess when performing a pen test. These 10 laws do an excellent job of describing some of the limitations of security:
If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore.
Attackers often attempt to encourage the user to install software on the attacker’s behalf. Many viruses and Trojan horse applications operate this way. For example, the ILOVEYOU virus succeeded because unwitting users ran the script when it arrived in an e-mail message. Another class of applications that attackers prompt a user to install is spyware. Once installed, spyware monitors a user’s activities on his computer and reports the results to the attacker. Sometimes the attacker will not even need to persuade you or a user on your network to run the exploit code—your computers might be set up to do this as was the case with code injection attacks such as SQL or thread injection attacks.
More Info
See Chapter 18, for more information on SQL injection.
If a bad guy can alter the operating system on your computer, it’s not your computer anymore.
A securely installed operating system and the securely procured hardware on which it is installed is known as a Trusted Computing Base (TCB). If an attacker can replace or modify any of the operating system files or certain components of the system’s hardware, the TCB can no longer be trusted. For example, an attacker might replace the file Passfilt.dll, which is used to enforce password complexity, with a version of the file that also records all passwords used on the system. If an operating system has been compromised or if you cannot prove that it has not been compromised, you should no longer trust the operating system.
If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.
Once an attacker possesses physical access to a computer, you can do little to prevent the attacker from gaining administrator privileges on the operating system. With administrator privileges compromised, nearly all persistently stored data is at risk of being exposed. With nearly all operating systems, it is generally a trivial matter to extract the account information or otherwise attack persistently stored credentials on the computer to obtain administrator access. Similarly, an attacker with physical access could install hardware or software to monitor and record keystrokes in a way that is completely transparent to the user. If a computer has been physically compromised or if you cannot prove otherwise, you should not trust the computer.
More Info
See Chapter 23, for more information about how physical access can be obtained and exploited.
If you allow a bad guy to upload programs to your website, it’s not your website any more.
An attacker who can execute applications or modify code on your website can take full control of the website. The most obvious outcome of this is an attacker defacing an organization’s website. A corollary to this law is that if a website requests input from the user, attackers will attempt to input bad data to disrupt the application. For example, you might have a form that asks for a number between 1 and 100. While valid users will enter numbers within the specified data range, an attacker will try to use any data input that might break the back-end application.
Weak passwords trump strong security.
If users and administrators use blank, default, or otherwise simple passwords—even when a network design is thoroughly secure—the security will be rendered ineffective and somewhat irrelevant once an attacker cracks the password. Weak passwords and weak password reset processes are the absolute lowest common denominator of penetration testing and attacking networks; it simply does not get any easier than this.
More Info
Chapter 15, discusses weak passwords and how to establish countermeasures.
A machine is only as secure as the administrator is trustworthy.
One constant on all networks is that you must trust the network administrators. The more administrative privileges an administrator account has, the more the administrator must be trusted. In other words, if you do not trust someone, do not give that person administrator privileges. From the standpoint of a pen tester, administrator credentials are particularly valuable because they are generally the ultimate asset.
Encrypted data is only as secure as the decryption key.
No encryption algorithm will protect ciphertext from an attacker if she possesses or can gain possession of the decryption key. Encryption alone is not a solution to a business problem unless there is a strong key management component and unless users and administrators are vigilant in protecting their keys or key material.
An out-of-date virus scanner is only marginally better than no virus scanner at all.
New computer viruses, worms, and Trojan horses are always emerging and existing ones evolving. Consequently, antivirus software can become outdated quickly. As new or modified viruses are released, antivirus software is updated. Antivirus software that is not updated to recognize a given virus will be unable to stop it. The patch management corollary is that it does little good to patch a system that was never secure to begin with. Computers that have outdated security provide excellent opportunities for attackers and pen testers alike.
Absolute anonymity isn’t practical, in real life or on the Web.
Two issues related to security that are often confused are privacy and anonymity. Anonymity means that your identity and details about your identity are completely unknown and untraceable; privacy means that your identity and details about your identity are not disclosed. Privacy is essential, and technology and laws make achieving it possible. On the other hand, anonymity is not possible or practical when on the Internet or when using computers in general.
Although technology can secure computers and computer networks, it is not—and will never be—a solution in and of itself. You must combine technology with people and processes to create a secure computing environment. From a pen testing standpoint, technology should not be the end either—that is, people make excellent targets as well.
Q. | I found a bug in Windows that lets an administrator open a user’s files, but the MSRC told me that this is not a vulnerability—what’s up with that? |
A. | It is not a vulnerability as far the MSRC is concerned. If the attacker already has administrator access, there are probably 10 easier ways to get access to the files and virtually no way to prevent it. To read the complete MSRC definition of vulnerability and its rationale, see the article "The Definition of a Security Vulnerability" on the Microsoft website at http://www.microsoft.com/technet/archive/community/columns/security/essays/vulnrbl.mspx. |
Q. | I read this chapter, but I don’t understand what it has to do with pen testing. |
A. | Although on the surface penetration testing might seem to be more about breaking into networks than securing them, as a penetration tester your value is in helping your organization beat the bad guys. The skills that you build as a penetration tester will have tremendous benefit in designing and implementing security. |
Q. | If there is one thing from this chapter that I should take to heart, what is it? |
A. | Good question! The answer is in-depth defense and deny access by default. OK, those are two things, but if these are the only two things you learn from this book, your money has been well spent. |
Q. | Where can I learn more about threat modeling? |
A. | Take a look at Chapter 4, "Threat Modeling," in Writing Secure Code, Second Edition (Microsoft Press, 2003). |