The System/Application domain refers to the technology and application software needed to collect, process, and store company data. This domain covers a broad range of topics from the systems that process information to data handling. It covers all the security issues associated with applications. Consequently, the types of standards in this domain are diverse.
The document collection in this domain can be quite large. There is a great deal of variation in applications. It’s important that the collection be well organized. Here are a few examples of what should be considered in organizing the collection of System/Application domain policies:
With such a diverse set of security issues, many of the standards within this domain focus on classifying assets and assigning accountability. Accountability includes who owns key decisions over the assets and who maintains the security controls. This distinction between the owner and custodian of assets is in many standards. The owner is generally considered the ultimate authority on the use of a resource or data. This means approving the resources and data that are used. A custodian is someone with daily operational control over the use of resources and data. The custodian is generally responsible for ensuring that proper approved processes are used to secure and handle the resources and data.
The Information Classification standard, for example, helps employees determine the classification of information. This type of control standard also helps you identify procedures to protect the confidentiality, integrity, and availability of data. The following are example control statements in an information classification standard:
All the organization’s employees and contractors share in the responsibility for ensuring that the organization’s information assets receive an appropriate level of protection by observing this Information Classification policy:
The Production Data for Testing control standard is an example of a policy dealing with data handling. This standard outlines the controls needed to prevent the use of production data for testing purposes. This standard may require that the data be sanitized or scrubbed before being used for testing.
Other standards related to the System/Application domain include those listed in TABLE 10-3.
TYPE OF CONTROL STANDARD | DESCRIPTION | EXAMPLES |
---|---|---|
Separation of environments | Establishes the need to separate the development environment from the production environment Outlines the rules and conditions for promoting application software between environments |
Logical or physical access control Prohibition of compilers on production computers |
Physical security control standards | Include a number of standards for physical security and datacenter access controls | Physical access authorizations Physical access control Monitoring physical access Visitor control Access records Power equipment and power cabling Emergency power, lighting, and shutoff Fire protection Temperature and humidity controls Water damage protection Delivery and removal of assets |
Developer-related standards | Specify secure coding and developer standards | Developer workstation and account configuration management—limits or grants the rights to developers to change their workstation configurations Developer security testing control requirements Secure coding standards, including published programming standards and developer training requirements Information accuracy, completeness, validity, and authenticity Malicious code protection Error handling |
Authentication | Specifies the authentication method and identity store to be used | Applications may be required to use Active Directory (AD) to authenticate all access to networked devices. |
The baseline standards in this domain deal with technology configurations and technical requirements. The following is a sampling of standards:
For each baseline technical standard, you may need to create a procedure document for administrators and developers to implement the control requirements. You could also have procedures for incident handling, monitoring, and reporting. Some organizations have procedures for using penetration-testing tools.
As with other domains, change management is an important procedure. In this particular domain, the project management life cycle (PMLC) plays a central role. The PMLC typically outlines the procedures a team follows to implement an IT project, such as developing a new software application. The PMLC is a specific series of steps and procedures. These steps have safeguards that ensure the prior step’s deliverables are complete.
With such a diverse set of security issues, the standards cannot define every situation. Guidelines are useful as education vehicles and for offering recommendations. For example, software developers might have guidelines for secure coding of .NET, Java, and other leading languages. The guidelines promote secure coding habits and educate developers on specific threats.