If you do not know your objectives, you do not know if you reach them. Define goals that are meaningful and measurable. A meaningful goal is: to protect the network from day-zero attacks, prohibit unauthorized processes and data transmission, and increase system stability. This clearly states an easily understood and important objective of CSA deployment, but the stated objective is not readily measured.
An example of an objective statement that is both a meaningful and measurable goal is: to reduce downtime and lost revenue through the implementation of CSA. Management loves simple and clear statements like this—non-technical and promising tangible benefits.
Of course, a statement such as the previous example is vague and does a technical implementation team absolutely no good, but it does get your team political support from management. Your technical objectives are discussed in further detail in the following sections; they should be specific and technical.
There are two main criteria to keep in mind when selecting which applications and systems CSA should protect: the value of those applications and systems to your business and how easily exploited applications and systems can cause interruptions on your network and truly critical systems and processes to fail. Some applications or systems in your organization might not be worth the time and expense to secure them with CSA. Determine what level or importance is the threshold for CSA protection. However, other noncritical processes, such as a brochure-ware website running on an unprotected server, can be compromised in such a way that they can take down all other business operations on the network.
It might be that your goal is threefold: to install CSA on every host in the environment, to protect all applications to a basic degree, and to ensure that critical applications have special protections from specially crafted policies. You might not have the time or money to install CSA on all your hosts and tune policies. If that is the case, carefully choose which hosts and applications are protected by CSA with regard to value and vulnerability.
The organizational impact felt by a CSA implementation is different for every organization. Organizations that follow rigid processes and do everything according to written policies should not experience much impact, but most organizations experience some pains caused by CSA. Unless your organization is in need of radical change, your goal should be to minimize the negative impact experienced throughout and after a CSA deployment. Of course, the positive impact of fewer security incidents should be maximized.
Many of the problems that users and server administrators complain about occur when the written Security Policy is not followed. CSA forbids prohibited activities from taking place, such as a server administrator running an rsh daemon on a server for easy administration or a user installing application upgrades from the Internet before the proper support mechanisms for the new application are in place at the helpdesk.
This is a good place to note that management needs to be aware that problems caused by CSA, although sometimes real, are often greatly exaggerated. Explain that CSA is powerful and monitors and regulates all processes on a host, and CSA sometimes blocks legitimate actions because that activity looks suspicious. Because CSA is powerful and flexible and few people within an organization understand what CSA does, it is a convenient explanation of anything out of the ordinary.
In the early stages of one deployment, one of the authors was informed that CSA caused approximately 1500 users located across 20 branch offices throughout four states to be totally down and unable to access any network applications or data. Management was upset that this new software, which had been installed to prevent such problems, was actually the cause of a large outage. After a brief investigation, the actual problem was identified as name resolution configuration on two workstations and the other 1500 users and workstation were unaffected and operating as normal. Be prepared to defend CSA from the blame of every glitch on the network. Sometimes CSA does cause problems, but careful planning helps prevent them.
CSA gives IT organizations more time to test patches for compatibility issues with applications. The manufacturer often rushes the latest security patches out the door with little testing for real-world application interaction. Sometimes the cure is worse than the disease.
Lengthening the patch cycle has many intangible benefits; the time to perform thorough testing is probably the most important. Another benefit to your organization is the ability to schedule a time when patches are applied on your terms, rather than as they are released. Setting a schedule also makes the lives of the server administrators who have to apply the patches easier, because they will not be expected to apply patches for vulnerabilities during maintenance windows with little notice.
Organizations using CSA properly enjoy increased system stability and worry less about day-zero attacks and incidents. Increased system stability leads to greater revenue and profitability for your organization, and it also helps you at performance review time.
As described in Chapter 8, "Basic Policy," the goals of information security are confidentiality, integrity, and availability (CIA). The objective of all security measures is the CIA Triad. Stability is assured by making sure that the three pillars of information security are upheld.
Another technical goal might be to protect against a specific vulnerability present in your systems. If you want CSA to protect against something like buffer overflow vulnerabilities in a specific application, make sure you state that in your project goals and that you test it. Again, look to problems that you had in the past to create a list of specific vulnerabilities that you want CSA to cover.
Was this article helpful?