As a disclaimer, I am also a info sec grad student and have done my fair share of research around this topic. The majority of my research indicates that is not a lack of frameworks in place it is a fundamental misunderstanding of the concepts of security. What happens, at least on every project I have been on (private and public sectors) is that a non-technical person is assigned to be the technical lead or a non-security person is assigned to be the official auditor of a system. What happens in these scenarios is that development cycles seem to be "delayed" because of increased security controls, for instance Tripwire, HIPS (Mcafee's special brand), the anti-virus system, and the automatic backups that occur on encrypted drives. Couple this with the borderline useless STIGS and other technical controls that other teams think are ensuring protection.
As a quick sidebar, the STIGS are useless because:
1) You can write a POAM and completely ignore the STIG
2) A completely STIG'd box can be broken just as fast as a non-STIG'd box
So basically what happens in this scenario is that the development/test teams will complain to leadership that it is impacting their performance as well as the performance of the application. Since it is "easy" to snow someone without a technical background on these issues often times there will be a member or two of a team that is assigned to write POAMs to get the security controls removed. That being said, if you want to have a framework in place it must be at the expense of time and at the expense of "frustration" on the development team.
In terms of securing the environment, the most important thing to realize is that everyone on the team could be a threat, whether it be intentional or unintentional. So we first need to minimize the level of damage that these types of individuals can do. This is where the concept of job rotation comes into play, every 60-90 days (for instance). By forcing the team to switch positions you theoretically increase security as new eyes are brought into the environment and it additionally forces username/passphrase (notice passphrase not password) combinations to be updated. By doing this it also increases the robustness of the team as people will not get bored as easily and can therefore continue to expand their horizons. Please remember I am not saying make a DBA the new physical security guard at the nuclear plant, keep them in technical positions or in whatever field they are specifically trained.
In terms of protecting the system that the team will be working on (individual workstation) it is the standard anti-virus+anti-malware+HIPS/HIDS (if it is truly critical only). As a step of added caution remove all optical drives and solder off all USB ports, if this is not practical install software that is managed from an outside system that reformats anything that is inserted into a USB port, still disable optical drives.
In terms of the network in where the team will be working. Have an established whitelist of IP addresses that developers can hit, this prevents them from setting up FTP servers via a small jar and transporting files to their home systems. It is also of great importance to disable access to sites that are proxies as they have no business trying to hide what they are doing in the environment anyway. Ensure that your configuration files are not sitting on public web servers and also ensure that developers do not have access to these systems.
At the end of the day keep all systems up to date and use diverse vendors to prevent one system compromise from impacting every other one.
WHAT A STIG IS
Since a STIG may be an esoteric piece of security literature I will explain what they are. An example of where these can be found: Windows 7 STIG
This is a step by step checklist of common and known attack vectors and/or weaknesses found inside the default settings of a specific type of application. By following this checklist security is potentially increased, the counter-measure to this is to write a POAM which nullifies the specific check that you need for operation. They exist for a myriad of application types, some specific such as Oracle, and some generic such as , database.
Response to why the Enclave STIG does not necessarily equal a framework
I have read over the enclave STIG and while on the surface it does appear to be a guide of sorts it still forces you to abide by a series of STIGs that are nothing more than checklists. Also, when a review comes up you fail each and everything that the auditing framework does not account for, example being BSD. Since there is no GoldDisk (their scanning tool) for BSD all of your systems that run it are considered completely vulnerable to everything (that an OS could be vulnerable to). Now I will agree that it does provide some very specific architecture and a series of ports that you must disable I would not however call this a framework. It is more of a failed attempt at a security design pattern than anything. I say this because it is mathematically impossible to implement all STIGs for your system and maintain the CIA and have the system function as it was intended.
