In addition to the following controls, consideration should be given to the security impact of an application’s architectural design. For example, the separation of application components (e.g. frontend, application service, database service, etc.) onto separate hosts can help reduce the risk of a compromise to one of the individual components. Similarly, placement of these components into network segments with appropriate degrees of security can also help protect the application as a whole. For example, it might be appropriate to place an application’s database server on a more restrictive network segment than the application’s frontend service. The type of institutional data involved and available resources will both play an important role in making architecture decisions.
|AS||1||Application development includes reviews for security vulnerabilities throughout the development lifecycle||Recommended||Recommended||Required|
|AS||?||Application development lifecycle includes planning for correcting code to eliminate vulnerabilities as needed||Recommended||Recommended||Required|
|AS||?||Application development takes place on a development server, and is tested before updates are transfered to production||Recommended||Recommended||Required|
|AS||2||Application change control procedures are documented and followed||Recommended||Recommended||Required|
|AS||3||Controls are in place to protect the integrity of application code||Recommended||Recommended||Required|
|AS||4||Application validates and restricts input, allowing only those data types that are known to be correct *||Required||Required||Required|
|AS||5||Application executes proper error handling so that error messages do not reveal potentially harmful information to unauthorized users (e.g. detailed system information, database structures, etc.)||Required||Required||Required|
|AS||6||Default and/or vendor supplied credentials are changed or disabled prior to implementation in a staging or production environment||Required||Required||Required|
|AS||7||Functionality that allows the bypass of security controls is removed or disabled prior to implementation in a staging or production environment||Required||Required||Required|
|AS||?||Applications support web single sign-on integration (SAML/Shibboleth)||Recommended||Recommended||Recommendedtd>|
|AS||?||Higher assurance authentication should be used for administrative accounts||Required||Required||Required|
|AS||?||Password complexity for applications meet or exceed the University’s Higher assurance authentication should be used for administrative accounts||Required||Required||Required|
|AS||?||Applications make use of granular role based management||Required||Required||Required|
|AS||?||Granular access management includes role and file based controls||Required||Required||Required|
|AS||8||Application sessions are uniquely associated with an individual or system||Recommended for READ access; Required for all other access||Required||Required|
|AS||9||Session identifiers are generated in a manner that makes them difficult to guess||Required||Required||Required|
|AS||10||Session identifiers are regenerated a change in the access profile of a user or system *||Required||Required||Required|
|AS||11||Active sessions timeout after a period of inactivity||Recommended||Required||Required|
|AS||12||Applications are periodically tested for security vulnerabilities (e.g. vulnerability scanning, penetration testing, etc.)||Recommended||Recommended||Required|
|AS||13||Application security patches are deployed in a timely manner||Required||Required||Required|
|AS||14||Successful attempts to access an application are logged||Required for privileged access; Recommended for all other access||Required for privileged access; Recommended for all other access||Required|
|AS||15||Failed attempts to access an application are logged||Required for privileged access; Recommended for all other access||Required for privileged access; Recommended for all other access||Required|
|AS||16||Attempts to execute an administrative command are logged *||Recommended||Recommended||Recommended|
|AS||17||Changes in access to an application are logged (e.g. adding, modifying or revoking access)||Required||Required||Required|
|AS||18||Application logs are reviewed on a periodic basis for security events||Recommended||Recommended||Required|
|AS||19||Application logs are protected against tampering||Required||Required||Required|
AS-05: Input validation plays an important part in application security. For example, if a data entry field is asking for a phone number, the application should validate that the value entered matches a format similar to (###) ###-####. If a data entry field is asking for a date, the application should validate that the value entered matches a format similar to MM/DD/YYYY. If an application does not have controls in place to validate input, a malicious user may be able to enter data that results in unintended consequences, such as application failure or unauthorized access to potentially sensitive data.
AS-12: Not only should a session identifier (SID) be unique to an individual or system but it should also be unique to an individual’s or system’s access profile. For example, a user has a certain access profile prior to authenticating. This access profile may consist of limited functionality and access to a very limited subset of data. Once authenticated, a user may have access to increased functionality and a larger data set. A new SID should be generated and associated with this authenticated access. Similarly, a user may be able to enter a secondary set of credentials in order to gain access to administrative functionality. A new SID should be generated and associated with this administrative access. If a user has both a user session and an administrative session active, that user would have two different SIDs associated with two different sets of actions.
AS-16: Administrative commands are those commands that typically require some level of privileged access to execute. For example, adding and deleting users of an application, resetting a user’s password and modifying how an application is configured are all examples of administrative commands that should be logged. Execution of administrative commands may occur through some type of command-line interface or they may occur through access to a graphical user interface. The full scope of administrative commands that should be logged may vary from application to application depending on the application’s inherent functionality, the platform(s) it runs on top of or interacts with.