CSSLP Tutorial: Module 07,Part 01 – Introduction to Secure Installation and Deployment




This last module is what needs to happen with our software and application once the software’s been designed, developed, signed off and we’ve gotten acceptance from our customer. The next role to play is in implementation or deployment of the software in a secure manner.  Eventually, at some point in time, it will outlive its original usefulness and then we may have to devise some method of its disposal.  We will still want secure installation and deployment to be placed properly, isn’t it?

When we are in the process of installing the software, we will want to make sure to do so securely. We need to make sure that the system itself is secure.  No matter how secure a system is, there’s possible interaction with the environment.  So if the environment is someone unsecure, then that could lead to problems with our system. So, a concept is called hardening and we talk about hardening our system.  That is, the having of our system be even more secure in its setup.  In this section, not only do we incorporate the hardening of our system, but we also talk about release management, bootstrapping and secure startup.

The hardening of a system is basically where we are talking about working to make our security system even more secure, and even more strong against an attack.  We want to make it where there is less attack surface. When talking about hardening the system, really everything should be hardened.  The operating system, hardware, software, firmware and so on everything should be more hardened.  This particular section is where we are talking about operating systems and applications.  The minimum security baseline should be configured for it to be in compliance with business objectives and standards.  This way then we are enforcing security policy.

Part of the security policy is to establish a minimum baseline, where there are basic configuration settings that all of the systems or at  least all of the systems of the OS should be configured to run.  There are elements which are part of this minimum baseline and will be important to factor in as such as keeping the operating system itself patched and up to date, keeping track of administrative accounts, and reducing the attack surface.  The idea is to reduce the more common security vulnerabilities.  The elements make sure that the system hardens to a particular degree.   In addition to the settings of the system, we still have to keep applications up to date. So, there needs to be some kind of strategy and also a way to assess the strategy as a method of fixing whatever vulnerability that may have arisen.  There’s hotfixes, patches, and serve packs which are all items which can come together and including other upgrades to the system, as an overall of a service pack.

There are at least four other elements which will also harden the system.  They include removing all maintenance hooks,removing any unnecessary services,  removing any misconfigurations but keeping up with change management processes, and finally, removing any default accounts on our system.  So the first one is as the development process is in place and the others are as a part of how we configure our system. The overall is so as to reduce the attack surface, making our system more resilient and lessening the vulnerabilities to our system as much as possible.

The first element to discuss is getting rid of maintenance hooks. These are basically messages that the developers have left for themselves like flags for places that need debugging.  Sometimes, these are more like comments which is fine when we are in the development stages.  But, once the program is set to go into production, all these need to be removed. Firstly, they may be comments of a sensitive nature and secondly, they may also indicate a level of professionalism. Obviously, it would be a lack of professionalism if they are left in place.  Whether it’s an individual system or any other type, points to consider as we discuss removing hooks, flags and comments which can then also can be correlated with the other elements for hardening the system as well.  They are important as related to the hardening of the system: if it’s not necessary, get rid of it.

As part of the getting rid of the unnecessary schemata, also can remove any unnecessary services.  Any of the services which are just there floating around and aren’t being used, they each then represent an opportunity for an attacker to gain access to the system.  This is a main important piece relative to hardening the system. Another point of the hardening process is then also keeping the system up to date with patches and hotfixes and such.  Another aspect of hardening the system is also related to changing the default settings from the focus being of ease of use to rather being more focused on keeping the system secure.

Either one of two situations which can lead to a less secure system, one is where we’ve confused our configurations to where it’s all misaligned or where we‘ve implemented something straight out of the box and haven’t bothered with configurations at all.  Either of these two situations can lead to a more vulnerable state.For example, if you have IP version 6 on your system but you are running windows 7, the IP version 6 isn’t really not used. So, if it’s not being used, why have it installed in the first place.  When something is additional  and unnecessary for your purposes, the best bet is to utilize the change management process.  There’s no reason for an individual to change something and bypass the normal considerations for change, as associated with your organization or business. Even though there is the management system to process through, being aware of possibilities of those points of accessibility is good to consider.

Thinking of unnecessary services we’d have to consider through the change management process, why don’t we just dump the extra service or get rid of them, to help again with increasing the hardness of our system?  To be honest, we may not be aware of the fact that are some background or networking services that the IP version 6 is offering.  So, if I turn it off on my own volition and not realize I’ve then turned off features like branch office caching or some other feature and by turning it off, then that feature or mechanism is restricted and no longer able to function.  So, when we’re saying “if it’s unnecessary, get rid of it” , what is really meant by it is to initiate the change management process.

The last element to help harden the system is to get rid of default accounts. A lot of vendors continue to use the username of admin and the password of admin or password.  A lot of vendors are using the same wireless ip address access point of 192.168.100  , which leaves a very unsecure situation because everybody knows these. The default configurations are common knowledge and when they have been left in place, then it is easy for an attacker to go in and make modifications.  The important aspect of this is to change the default settings and get rid of the default accounts.  Part of the psychology behind the user keeping things at default is ease of use.  Vendors don’t want to be known as the difficult ones to where it takes a person over an hour to reach a certain access point, for example. As another example is Microsoft and how the ease of use where users can use straight out of the box default settings, which is why Microsoft is so popular.  However, having this ease of use is problematic in that the settings are not as secure as they could be. So, in reference to the hardening of the system, best bet again is to change those that are in default.  There also is an important aspect of making sure that there is a process that reviews in order to make sure that our system is patched, that it will receive updates and upgrades.

Not only do we need to worry about hardening the system, we also need to discuss the implications of the environment and how to make sure that the environment  is secure as well.  Before ever bringing the product out to production, the product will have to go to the simulation lab. The lab environment is meant to mimic the production environment as closely as possible.  However close as we can get, there will be differences. For example, there may be differences in the communication supports, different interfaces, different types or amounts of privileges and so on.  The closer the lab simulation is to the production process, then the greater is the assurances that the testing shows validity and more accurate results as to how the program will behave when out among various users.

Microsoft is an operating system which would operate under the philosophy of having all the doors open for their users; this is the ease of use position.  Most other operating systems will instead close all the doors. And they say here’s how to open them if you want them opened, if you want to.   So, that’s a totally different approach. The more secure philosophy is to close all the doors and then allow users to open them if they want. Firewalls and other such aspects are basically what work to keep doors shut in the OS, and the bottom line is that access is denied.

Last is the release management. This goes hand in hand with change management.  This is the process where we are making sure that any changes to our environment are planned, documented, tested, approved and deployed ideally without having any sort of negative impact on business.  We want to make sure that we have figured out the updates and how they are to be distributed over time, and want the releases to be on a certain schedule. We need to be diligent in our studying over which specific approach. Due diligence is also is also towards the documentation and communication.  They both go hand in hand with release management.

This module pretty much covers what happens to our product, once the software has been designed, developed, signed off by the customer. So, first is to deploy the software in a secure system and having a secure environment as well.  Then, hardening the system to make the overall much more secure than originally devised. Then, releasing the product for production line and once it’s pretty much outlived its usefulness, to destroy the software still in a secure manner so as to not compromise potentially sensitive information.