By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Your issue is shared with security personnel throughout private and government sectors. Security personnel have long held the understanding that the first step in the life cycle of application/program development or acquisition, is defining the security administrative/technical requirements of the system/application. (Specifications are usually defined in the initiation phase of development). It is far less costly, more efficient and effective to incorporate security functionality in the design phase than to try to back it. Based on the requirements, the security and audit related functions would be defined. This is further enforced if your organization has C1 to A1, or trusted environment requirements. There is always a chance with delaying security functionality until later stages that functions will not work or other modifications will have to be made to the existing code. I would like to direct you to the DoD Rainbow series. Even though it is written for the government, many (if not most) of the same guiding principles hold true (follow the C1 specs). These sites may be of particular interest to you, as they are directed to "developers, purchasers, or program managers who must identify and satisfy requirements associated with security-relevant acquisitions:"
http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-010.txt Of particular interest will be some NIST publications:
Dig Deeper on Security Resources
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.