This chapter will introduce organization processes and methods that can be used to secure enterprise computer systems. The systems that we will focus on in this chapter are server systems that are used within the enterprise to conduct business functions. Processes and methods covered are system classification, system protection using anti-virus, host-based intrusion prevention system (HIPS), file integrity monitoring (FIM), and user account management. Additionally, challenges of implementation and opportunities to improve protection of systems will be covered. Each solution in this chapter should be independently evaluated to determine its value and suitability for purchase and implementation within the organization. There are several ways to approach system security, but to be effective, the approach must be in line with the defined security architecture based on the presented trust models. Some of the solutions provide better security advantage than others, and the consideration of layering technologies versus agile and lightweight implementation can be very effective in well-documented and mature environments. Lastly, the operational overhead of each solution has to be identified and proper staffing and supporting processes need to be put in place in order to ensure effective implementation of the solution.
This chapter will cover the following topics:
- Identifying critical enterprise computer systems
- Methods to secure enterprise computer systems
- Enforcing security policies on computer systems
In the previous chapter, we covered network segmentation and placing systems of high value and criticality to the enterprise in segmented areas of the network. In order to identify these systems, it is necessary to understand the important business processes and applications to determine what hosts maintain both. As with any classification model, there should be tiers based on criticality. There will be several "important" systems, but some are truly critical to business operations and others can be offline for a longer period before business is affected. The tiers of classification should have a criteria for each level to ensure all security and availability requirements are met as per the defined tier such as the business processes impacted. The tier classification may also include service-level agreement information based on how the system is to be connected to the network, expected recovery times, and the priority of security incidents involving the systems. The system labels applied will need to serve as an input to the overall security architecture and be referenced in other business processes such as change management, user account management, protection tool selection, monitoring, and incident response.
A system classification model may look like the following table.
|
Level |
Classification |
Process(es)/Function(s) |
Requirement |
|---|---|---|---|
|
1 |
Critical |
Transaction processing, Deposit functions |
Network redundancy, File integrity monitoring, User monitoring, Encryption |
|
2 |
High |
Payroll processing |
Network redundancy, User monitoring |
|
3 |
Medium |
Customer e-mail promotion functions |
Network redundancy |
|
4 |
Low |
Corporate communication processes |
N/A |
Individual systems will not be identified in the table, only processes or functions are. Labeling of the systems should happen in an asset management tool or a configuration management database (CMDB) if using the ITIL framework. The CMDB is the central database repository and the authoritative source of all assets and associated change information in a mature change management implementation. The complexity of the system classification model is dependent on the needs of the organization including any external auditing requirements. The enterprise may also decide to create a classification for systems that have regulatory compliance requirements for specific controls to be implemented. This is a good method to ensure these systems are always implemented in the same manner based on standards developed from the classification model. The model should generally mention technologies to be implemented along with required controls. Remaining non-specific is a good practice for policies and classification models; specifics can be provided in related standards.
Depending on the budget structure, required controls and network connectivity may increase the cost of implementation and should be well defined. Some considerations may include redundant network connections, additional installed monitoring tools, forensic tools, and operational expenses for security-specific capabilities. These items may not only incur additional costs to purchase, but increasing system resources for dual home connections to the network and increased memory and CPU must also be considered. The security cost of doing business should be included in every system build based on its classification.
Implementing and managing system users in adherence to the trust model and associated policies and standards should involve an identity and access management process for enforcement of user access controls. User authentication, authorization, and accounting should be implemented uniformly across all systems for complete audit data collection and post-incident forensic analysis. The more mature this process is, the easier it will be to maintain and defend during an audit if this is a required enterprise exercise.
System classification should be the basis for the location of the system within the enterprise network, security controls required, monitoring requirements, availability, and incident response priority. Though the network boundaries are constantly being redefined, there should be a segmented network to provide a more secure portion of the network for systems with high and critical classification. The segmented portion of the network may be where the most sophisticated security controls are implemented, as loss realized for other systems within the network may not have a significant risk of impact to warrant additional capital and operational expense to protect. It is important that, as in the case with data classification, system classification must be adopted by all IT groups and understood by the enterprise business units. Having a system classification will simplify implementation of security controls for important business systems and provide a solid basis for policies and standards for enforcement and consistent implementation.
An important part of securing systems and properly applying security architecture is proper system management. This is the process of inventory management, system labeling indicating system classification, system owners, and required security control mechanisms. Based on the classification of a system, patching requirements can be documented and enforced through policy. System management can also play a significant role in the change management process by ensuring that the security posture of the system is maintained through all expected changes. The next two sections will cover the importance of asset inventory and proper labeling of systems for security architecture implementation.
Once systems have been properly classified, asset inventory labels must reflect the classification to ensure the correct controls are in place and that policies and standards are enforced. Asset inventory management is critical to the overall security posture of the organization because critical systems will be properly inventoried and all pertinent information will be documented for securing and monitoring the assets. Without asset inventory there is no record of what systems exist, what data is located on the systems, and the risk introduced by the improper securing or loss of the systems. Leveraging the asset inventory function of the CMDB is critical for the change management process to ensure security controls are not intentionally or accidentally disabled or circumvented. Communication of the system classification labels must be a part of the organization's security awareness initiatives, understood by IT, and enforced.
System patching may be based on criticality of the system, the severity of the vulnerability, or impact of an unpatched software package. System classification should play a significant role in the patching cycle of systems and should be integrated in the patch and vulnerability management processes. The importance of system patching cannot be overstressed with the current threat landscape where the method of attacking dated vulnerabilities is still very successful. When systems remain unpatched and vulnerabilities continue to exist, the window is also extended for malicious actors to exploit. With other weaknesses in the network such as lack of segmentation, systems may be at greater risk when a strict patching cycle is not implemented. As with other components of the system classification model, patching requirements must be documented, communicated, and measured to be effective.