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.

Application Development

Area ID Control Public Confidential Restricted
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

Access Management

Area ID Control Public Confidential Restricted
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

Session Management

Area ID Control Public Confidential Restricted
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

Vulnerability Management

Area ID Control Public Confidential Restricted
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

Application Logging

Area ID Control Public Confidential Restricted
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

 

Supplemental Guidance

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.