Network is experiencing difficulties.
- IRT Division
- Vice President & Chief Information Officer
AIRC Rm 3010 (map)
Tools & Resources
- Students & Staff
- Security Services
- Training & Awareness
- Security News
Policy & Standards
|Information Systems Acquisition, Development, and Maintenance
Application Development Standard
|Number: 8070.0 Revised: August 15, 2010|
All application and web development involving handling of wither Level 1 and 2 data or access to data from off-campus must be in compliance with the following standards and procedures. All contracts for services involving application and web development involving either handling of Level 1 and 2 data or access to data from off-campus must also comply, prior to completion of initial contracting. All application and web developers are encouraged to consult with the Information Security Office prior to beginning such web or application development or contracting. Applications and websites handling Level 1 data may not be deployed prior to approval by the Information Security Officer.
Development Review Required
All developers anticipating or planning to work on web or application development projects involving handling of Level 1 or Level 2 data and/or access to that data from off-campus must notify the Information Security Office prior to beginning development. The Information Security Officer or his designee will review the proposed development to ensure:
There are no existing enterprise applications that meet the same need.
The proposed application is not already in development elsewhere on campus or within the CSU.
The application will be able to meet all applicable information security requirements.
Alternatives to direct use of Level 1 and 2 data have been considered.
Security measures are in place for security of all Level 1 and Level 2 data.
Web and application development procedures are on file. A template for web development procedures can be downloaded here. A supplemental web development guideline from the OWASP Testing Framework can also be found on the Information Security Website found here. This document discusses the phases as for development as recommended by the OWASP V3 development standard.
Work may not begin on application or web development using Level 1 and Level 2 data until written approval is received from the Information Security Office.
Campus Web and Application Development Architecture
Web and application development must be performed in a three-tier environment for all Critical Systems and for handling of Level 1 and 2 data. The tiers comprise a development tier, a test tier, and a production tier. Less critical development (e.g. business and academic applications) can often combine the development and test tiers, although use of the three-tier architecture is still recommended.
Used for building and preliminary testing of application code. Development systems can either be on a workstation or development server.
Development may be used at random or minimal test data from a production system for testing purpose.
Used for testing final application code against production setups and environment. The test environment must be a complete and current snap shot of the production environment and data. These test systems can be accessed by developers using SSL VPN connections.
Test systems must use a copy of production data to ensure the application has been fully tested against a production environment. Confidential data must be redacted were possible.
Used for the final application. Production systems code must never be modified while the system is in production. Applications in production that need changes must follow the process of development and testing before being implemented into production.
Production data must be maintained and protected and must not be modified for testing or development process.
Development and Testing Server
Servers must be housed in the campus-wide Data Center if they are Critical systems as defined in the Supplemental Information Security Policy section 8045.100 Security of Servers and Network Attached Devices. The Information Security Office may authorize additional data center locations if they meet appropriate physical and logical security controls. .
If a development or testing system requires exceptions to the above tiering, these exceptions must be documented and approved by the Information Security Office.
Development and testing servers must be placed in the appropriate network zone as required by the ISO, based on the data they are handling and/or value to the support to the campus.
Servers should be running minimal services, e.g. not running other web and database services if not needed by the production application.
Security-sensitive web-based applications must run on stand-alone dedicated servers or VM server containers; most Business and Academic systems may run on shared servers.
Limit the privileges of system accounts to least necessary access.
Limit the privileges of web developers to least necessary access.
If an application needs a system account, an approved and secure service level account must be created and incorporated into the development of the application.
Development and Testing Systems
Any application development done using IRT-managed server systems must be done in collaboration with the applicable systems administrator from the Operations & System Services team, using the approved ticketing method. This process will ensure that the systems administrator can tailor the security of the server and OS system to the needs of the application. Unencrypted Level 1 or Level 2 data will not be allowed to accumulate on public web servers.
Web Application Coding
Sacramento State Web Developers must use the secure code guidelines from the Open Web Application Security Project (OWASP). Applications must be reviewed and tested before being placed into a campus production environment to ensure that the following vulnerabilities are addressed:
• Un‐validated input
• Injection flaws
Web Developers must perform appropriate testing as outlined in the web development guidelines. All applications and information systems must be appropriately documented prior to deployment in a production environment. Application code created by a campus must be appropriately reviewed before being used in a production environment as determined necessary by risk assessment.
Other Application Coding
Developers of other applications must consult with the appropriate systems development manager in the Administrative Computing Systems group of IRT for appropriate secure coding requirements, prior to beginning development work.
Applications development on a Sacramento State system with files containing Level 1 or Level 2 data must be hosted in the IRT data center.
Web and application developers must remove all test data and test accounts before deploying an information system into a production environment. Once in the production environment, developers/application owners must work with the Information Security Office to conduct regular risk assessments to ensure the system has security controls that appropriately protect the confidentiality, integrity and availability of the system. Confidential data must not be displayed in any user documentation.
Web Surveys Collecting Personally-Identifiable Data :
Web survey subjects must be prevented from viewing any survey records other than their own.
Survey respondents must be informed of any personal data collected about them without their knowledge. Respondents must be given the option of not providing such information or not completing the survey before personal data are collected. Use of "web bugs," URL keywords, or other methods to track respondents' identities without their knowledge is prohibited unless survey respondents are informed in advance that their personal information will be collected. Web sites collecting personally identifiable survey information must provide on their web page a privacy statement that describes the kind of information that is collected, how it is to be used, and how it may be disclosed.
Remove all sample scripts
Development tools are commonly distributed with example or sample scripts included. These scripts often contain security holes and make a very attractive target to potential intruders. All un-needed sample or example scripts must be removed from Sacramento State production servers.
Inadvertent copies of Level 1 or Level 2 data
Developers must check their systems and their development tools to be sure that copies of Level 1 or Level 2 data files are not created without their knowledge. Servers and development environments that may contain Level 1 or Level 2 data must be scanned by the Information Security Office’s web application scanner for this fault prior to deployment.
Developers working with Level 1 or Level 2 data and transmitting this information over computer networks between users' browsers and the server must encrypt the traffic as required by the ISO.
SSL encryption for outside access
The SSL (Secure Sockets Layer) protocol is Sacramento State’s standard for protecting web-based network traffic. The SSL protocol protects data from alteration and disclosure while it is in transit. If an SSL certificate is required, a request must be sent to the manager of the Operations and Systems Services group to be assigned appropriate controls. A standard HEAT ticket request for an SSL cert may also be submitted.
Server to server
Applications that require accessing information between servers containing data bases and file shares that must be inside the campus firewall may not need to meet SSL Encryption standards. If the application requires accessing a server outside the campus firewall then SSL encryption or another encryption method must be used.
Server to client
Applications that require clients to access Level 1 or Level 2 data must use SSL or another form of encryption during the connection process.
Application User Authentication
Applications that require users to authenticate to the application must use the central campus authentication systems, as assigned by the ISO. If the application is not compatible with the campus authentication system, the Information Security Office must be notified in advance of acquisition to review and approve authentication methods.
Applications that require an account to authenticate to other systems at Sacramento State must use an approved service level account. A service level account must be requested through the Information Security Office using the form found at http://www.csus.edu/irt/is/accounts/serviceaccounts.html.
Applications that make provisions to authenticate each form that they submit and view must create a random session ID on the server side and store it on the client side. The session ID must consist of a long string of characters, which is stored as a hidden field or is embedded in the URL. The session must be encrypted and the session ID must not be exposed when it travels over the network. Session IDs must be long enough and sufficiently random that they are very difficult to guess.
Validate input of Data
All data must be validated from all un-trusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. External data sources, including command line arguments, network interfaces, environmental variables, and user-controlled files must have logging enabled on the application system.
Sanitize data sent to other systems
All applications must sanitize all data passed to complex subsystems such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Applications must be able to prevent attacks through the use of SQL, command, or other injection attacks.
Sacramento State default access to all application is based on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is specifically permitted. Systems that use a service level account must use an account that authenticates to the central campus Active Directory.
Limited number of accounts
The number of user accounts on the system should be kept to the minimum necessary. This minimizes threats because it limits the number of accounts capable of attempting to elevate privileges without authorization.
Principle of least privilege
Each application process should execute with the least set of privileges necessary to complete the job. Any elevated permission should be held closely and access documented and approved through the Access Control Process.
All web and application code must undergo appropriate testing and code review of all developed or procured applications and information systems before deployment in a production environment. The security of all such applications and information systems must be appropriately documented prior to deployment in a production environment.
Developers must test the information system’s security controls in cooperation with the Information Security Office. This test must verify that controls are working properly and must be conducted prior to deploying the system into a production environment. Developers must document the test plan(s) and test results. Previously deployed systems must be tested as part of any significant upgrade or as determined by risk assessment.
A code review is the process of reviewing application code to locate potential security flaws and functionality problems. Any security flaws found should be entered into a defect tracking system, clearly identified as a security defect and fixed before the application is released.
Application reviewers should be objective parties holding no responsibilities for developing the application being certified. The application reviewer should have a strong background in the languages used by the application, as well as training in identifying security flaws.
Code reviews may be automated or manual, and there are many commercial companies offering code review services. The most comprehensive reviews will implement two or more of the review types.
Manual Code Review
A manual code review is performed by one or more application code reviewers. Manual reviews are more time consuming than automated reviews and are reliant upon the skill and experience of the reviewer to find security flaws, but they have the advantage of being able to detect forms of vulnerability that might not be found through automated analysis.
Automated Code Review
Automated code reviews can quickly identify weak areas of an application. Depending on the sophistication of the analysis, static analysis tools may be prone to false positives and may miss some classes of security defect. Automated code review procedures should be put in place to disqualify false positives and manually check for security vulnerabilities the tool fails to identify. Static analysis tools are valuable if the code is very large, but it is not a replacement for manual code review. There should be manual code review for exposed code, such as Internet-facing code and mobile code. Work with the Information Security Office to schedule a scan with the campus web application scanner.
Third Party Code Review
Several commercial companies offer code review services. These companies use a mixture of automated reviews and manual reviews by experienced auditors. Third-party review is valuable if the application is highly exposed, is large, or cannot be manually reviewed in depth.
Web application scanners allow testers and application developers the ability to scan web applications in a fully operational environment and check for many known security vulnerabilities. Web application scanners parse URLs from the target website to find vulnerabilities. These scanners check web applications for common security problems such as SQL injection, cross site scripting, command injection, buffer overflow, session management, and other vulnerabilities. These tools can be used to satisfy code review requirements based on the security checks provided by the tool.
Critical Systems must be scanned with an approved web application scanner at least annually by the Information Security Office. Credentials to all web application pages must be provided to the Information Security Office. Scan results must be reviewed and issued, remediated, or mitigated by the web developers based on the documented timeline. Web application scanning should be used on each web application release prior to deployment to a production environment.
All web systems are scanned with a baseline system scanner by the Information Security Office weekly. Scan results must be reviewed and problems remediated or mitigated by the web developers prior to deployment.
Source code and other critical files/folders must be assessable by only a Primary Application Administrator and a backup Application Administrator from the web developers.
Procedures for implementing changes to applications must be documented. The documentation must include:
Roles and Responsibilities – who is the Primary and Backup Application Administrator
Code review process
Should reference coding standards
Patching cycles and timelines
Vulnerability management cycles and timelines
Scanning windows for web application scanning, if Critical System
Monitoring / Audit
Developers must implement a change management procedure for all future code development of an application at Sacramento State. These change management procedures must be audited yearly to ensure proper handling of development process.
Conduct Periodic Reviews
Regular health checks should be performed on both the application and supporting infrastructure to ensure no new security risks have been introduced and that the level of security is still intact.
Back to to Sacramento State Information Security Policy Website
Information Resources and Technology | Sacramento State | 6000 J St | Sacramento, CA, 95819-6065 | AIRC Building | 916.278.7337
If you have difficulty accessing content on this page, please contact the webmaster.