So this is my current project. It's the beginning of "cloud" infrastucture based on Open Stack and Ceph. I can share this because anyone that reads about these 2 technologies will come up with this same design in all of about an hour. EAT is another one of the pillars of EA. And like all the other pillars one of the concepts that this can not, and should not be done, as a one shot deal. This is an interative process. And in a lot of cases, the different pillars of a good EA program are running concurrently.
EA is generally a motivator and instigator of change. Sometimes drastic, sometimes not. It depends on the goals and strategy of the business, or should anyway. In my case, with this project, it is a pretty big change to the way our infrastructure is built. One of my main objectives is decouple from vendor lock in. With that I would like to migrate from our VMWare infrastructure to one based, at least partially, on Open Stack and other FOSS. The process though has to be iterative because of the nature in working a DoD environment and the strict standards we have for security.
With my project I have a phased approach because if it can't be proven and documented as secure it's sunk. It does not matter how much faster, better, or cheaper it is, if it doesn't pass security it's dead. First and foremost, my base OS's have to meet the STIGs[1]. This is good and bad. For one it's good because it's a very rigid set of settngs the base OS must comply with. It can be bad based on the length of time it takes for those STIGs to be published. For example, the DRAFT STIG for RHEL [2] 7 was just released. RHEL 7 has been out for almost 2 years.
The drawing is fairly high level. Its essentially just the physical equipment and how they are connected. The document it's part of drills down further. But starting with this I was able to interface with my stakeholders and security people to determine what additional things were needed to be compliant with our IA rules. After this I was able to create another drawing (that I can't post) showed the security devices such as Rouge Device Detectors, Intrusion Detection, Identity Management, etc. This week I will create a services list that will include what services are running, what ports and protocols, their purpose, and who talks to who. This is all before I even put a CD in a computer and start loading software to see if this environment will even meet the "requirements" or needs we have.
If the environment fails, it still needs to be documented so that as EAT continues work and effort is not duplicated. Or if fixes, new software, so some other insurmountable hudle can now be mitigated and reevaluation can be considered. New concepts and software must constently be looked at and evaluated. But security should not be diminished for it. Docker is a prime example of that. It's a great idea and works well in production. The security of it is vastly changing though. It's great for running Word Press sites and things of that nature, but the security is not mature enough yet to really be of use. Red Hat and the Atomic Host Project have added a good amount of security to it via SELinux but it's still not that. It's a maturing enviroment though and soon it will be secure enough to host more sensitive applications.
No comments:
Post a Comment