Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Developing the Policy
Before you implement any procedures, you need to have your policies in place in order to have a goal to reach. Policies are not guidelines or standards, nor are they procedures or controls. Policies describe security in general terms, not specifics. Procedures are implementation details.
When you write policies, keep them general, so that the procedure can change should it fail. For example, there are many wonderful programs that help find potential buffer overflow problems or memory leaks. The policy should request that developers use one of these tools. But if you specify a brand or version, you will have to update the policy to remain compliant. Then the policy will have to undergo a review before being updated. Instead, let the brand and version be part of the procedures. Procedures have a different review cycle, usually shorter than for policies, which allows them to be updated as necessary.
Software development policies usually have three major components:
Software development process
Testing and documentation
Revision control and configuration management
Although there are other concerns, such as third-party development, it is not necessary to specify these areas when working with developers. For them, we concentrate on the software development process.