First Defensive Layer: Failure to Plan = Plan to Fail
In security, this familiar maxim holds very true: “If you fail to plan, you had better plan to fail.” Thinking about the defenses against potential attacks ought to begin early in your implementation projects. Both methods are the types of things that can be incorporated relatively inexpensively and with little effort if they are employed from the start. The costs and effort to adopt these principles will increase the further along you progress in your project. Trying to achieve this once your system is in production will probably involve ripping out significant parts of your code or infrastructure and replacing it with something new. While it may be necessary, it certainly will not be as cheap or as easy as if you had incorporated these principles into your approach early in the planning phase.
Segregation of Applications (Function)
This defense was mentioned earlier in the first attack scenario. In essence, it involves separating the components onto different platforms so that an attacker cannot compromise the entire system through compromising a single platform. In the case of SharePoint, as depicted in Figure 7.3, the SharePoint's back end – its SQL Server database – is installed on one server and the front end – IIS and MOSS – is installed on another server. This arrangement very closely resembles the well-known Information Technology (IT) security principle, Segregation (or Separation) of Duties. See Figure 7.3 for a description.
FIGURE 7.3. Separating SharePoint Components on Different Platforms
alt1 Note
The ISACA Glossary defines the Segregation of Duties, also referred to as the Separation of Duties, as “a basic internal control that prevents or detects errors and irregularities by assigning to separate individuals responsibility for initiating and recording transactions and custody of assets to separate individuals.”1 The intent of this principle is to reduce the scope for error and fraud. For example, users who create an output file with sensitive data are not permitted to authorize transactions that involve the use of the data. While there is no way to absolutely prevent collusion among employees, the Segregation of Duties is a deterrent. The additional benefit is that it can reduce the possibility of unintentional damage caused by accident or through incompetence by putting a second “set of eyes” on the particular activity.
Incorporating security requirements into the design of the infrastructure and application architecture will prevent security from becoming an afterthought or a last resort. Furthermore, new infrastructure and applications generally do not run in isolation. Public Web sites need to be exposed to the Internet; other applications may run in a highly classified network. In both cases, the applications will need to interact with security hardware and software, such as firewalls, intrusion detection, and antivirus software. All of these components, among many, many others, will have an impact on how new systems are accessed, how they are used, and potentially how well (or poorly) they perform. The earlier these other systems are identified and figured into the overall architecture, the easier it is to make allowances for them. As mentioned in the opening paragraph in this section, the more mature a system becomes, the more expensive it is to modify.
Secure Application Development
SharePoint is not merely a collaboration suite but a bona fide platform for workflow and forms-based applications. Furthermore, while you can deploy SharePoint without customization, the options that it offers to tailor it for your organization's look and feel mean that it probably will not be long before requests for customization start to roll in. Security needs to be a prime consideration for each piece of custom code that is written. Each batch of poorly written code is a potential vulnerability that can be exploited.
Security must be integrated into applications from the ground up. Tackling the topic of secure application development, also referred to as secure coding, is well beyond the scope of this book. In fact, there are entire books written on the subject. At a high level, security needs to be integrated in application development throughout the development lifecycle. The following are four areas where you as an IT security professional need to be involved:[2]
Often the security professional gets called in when a system is ready for deployment or has already been deployed. While the threat and risk assessment, vulnerability assessment or penetration test, among other possible activities, are worthwhile and absolutely necessary, this is too late. He or she needs to be involved in the early stages of planning and initial development. The functional requirements for a new application or a new release of an existing application that comes from end users are critical in determining the security measures that need to be built into the application. From these functional requirements, flow technical and data requirements need to be wrapped in an appropriate amount of security. You will need to understand the reasons why the application needs to be developed, or an existing application needs to be modified, who will be using it, and how it will be deployed and used.
With SharePoint, there will be ample opportunities to customize it to meet the needs of your organization. It also becomes a platform for delivering Web-based applications. Customization should be viewed as something that is done only when necessary. Every customization represents a potential vulnerability if the code for it is written poorly and security best practices are not heeded.
Testing is an absolutely critical activity that should never be taken lightly or performed as a formality. The key is that the right testing needs to be performed. Use cases need to be created to guide development and to serve as the basis for functional testing. These use cases, naturally, need to reflect the users' functional requirements; they also need to incorporate the appropriate security measures. There is little sense in testing an application with all of the security disabled. If this happens, there is no way to determine how the application will behave once it is deployed and the security is enabled. Furthermore, you will need to create what one author appropriately calls “misuse cases…cases that signify the misuse of an application.”[2] These cases highlight vulnerabilities that can be exploited through well-known attack methods and inadvertently through the ignorant use of the application.
Code review is the review of application code by peers or by third parties in order to discover and repair mistakes in the code that were introduced in the initial phases of development. As a security professional, you need to be involved in code review and if you do not have a background in application development, you should bring in the appropriate skills to search for known vulnerabilities. Code review, also called peer review, is not a one-time activity. It should be performed at every stage of development and then periodically throughout the lifecycle of the application. Because of its role in guaranteeing the stability and quality of the final product, code review should be inserted in to the development project's schedule before significant milestones, such as the completion of major modules, rounds of testing (unit, system, and user acceptance), and maintenance cycles where defects and other issues are addressed.
Risk assessment is a relatively straightforward activity and there are a number of models that are available. Most models are based on the following approach. The potential threats are identified. For each risk, ratings are assigned for the probability of each threat occurring, the impact, and the projected timeline. The rating can be as simple as selecting a number between 1 and 10 with 1 being the lowest ranking and 10 being the highest. The formula for calculating the priority of risks is Probability * Impact * Timeframe (P*I*T). These three elements multiplied together determine each risk's Risk Priority Number (RPN).[3] The prioritization is the significant exercise because it determines where the investment needs to be made. More effort should be devoted to mitigating an individual risk with a higher relative RPN than with a lower relative RPN. That being said, risks also need to be addressed and managed at a macro level to ensure that the new or modified system corporate obligations, regulatory standards, and industry best practices.
Second Defensive Layer: Leave No Hole Unpatched
You are probably tired of hearing this by now, but please do not stop reading. The reason for repeating the need for effective patch management in multiple chapters is that it is terribly important that it is not overlooked or trivialized. The avenue that an attacker could have used in both attack scenarios in this chapter is through neglected or poorly executed patch management. As mentioned in Chapter 2, “Active Directory – Escalation of Privilege,” in 2001, Nimda, Code Red, and Code Red II worms were so successful because many server administrators had failed to patch their IIS servers with a set of security patches that had been available for more than a year. In these two cases and many others, negligent patch management practices led to millions of dollars of damage in lost productivity, online sales, and reputation.
In the current day and age, a server administrator's options for patch management are plentiful, and there is little excuse for ignoring the application of patches. At the time of writing, Microsoft is still making Windows Server Update Services available as a free download. It is available as an out-of-band component in Windows Server 2008. Microsoft System Center Configuration Manager is also available for patch management, in addition to a host of other systems management functions.