Topics Map > Help and Training
Cybersecurity, Example Development Standards
Example Cybersecurity Development Standards
This is an aspirational document. A team should not expect to adopt every practice on this list overnight.
The purpose of this document is to help development teams associated with the University of Illinois fulfill their responsibility to comply with Illinois Cybersecurity standards, including IT-7, IT08, and IT13.
Use this document to guide discussion on your development team of current and future cybersecurity practices. Any standard adopted internally by the development team will be most effective if all team members understand and commit to it. To that end, teams are encouraged to use this document as a starting point to draft a more detailed specific document internal to the team, and committed to by all team members.
To aid understanding and adoption, see the "Why" section below that outlines the value provided by each suggested practice.
Development Team members will:
- Maintain a CHANGELOG file with a level of detail acceptable to members of the SecDevOps team.
- Annually complete cybersecurity development training covering the latest OWASP Top Ten guidelines.
- Establish and follow a team code review standard. Example code review standard
- Maintain regression test suites for all components. - When a bug is found, create a new regression test that confirms the bug and prevents the bug from being re-introduced.
- Provide modern API documentation with each release
- Consider Swagger or PostMan
- Cybersecurity, Endpoint and Data Stores Documentation Examples (uillinois.edu) provides details about documenting API endpoints
- Strive to focus each module, component, class and function on a single purpose. Simpler components are easier to test and less likely to have flaws that lead to vulnerabilities.
- Establish and follow team logging guidelines. Consider starting from these example logging guidelines.
- Commit to a process for creating and maintaining data flow diagrams.
- When introducing a new third party vendor, follow Illinois vendor risk guidelines
Operations team members will:
- Help automate and configure test suites and code and external scan tools, ensuring members of the SecDevOps team receive feedback from changes in a timeframe acceptable to members of the SecDevOps team.
- Enable cloud security tooling feeding into a security dashboard shared across the SecDevOps team.
- Perform Vulnerability Scanning as described at Security, Vulnerability Scanning Program, General Information (uillinois.edu)
- Why maintain a CHANGELOG? A CHANGELOG file facilitates coordination between diverse members of the SecDevOps team, which in turn reduces flaws that can be vulnerabilities. A CHANGELOG file is also a foundation component of a strong regression test suite.
- Why complete OWASP Top Ten training every year? The Open Web Application Security Project is compiled from data on actual vulnerabilities and exploits, and represents a broad consensus about the most critical security risks to web applications.
- Why participate in peer code review? Code review is effective at preventing defects. and Code review broadens knowledge of the codebase, elevates the teams performance and accelerates feedback loops. These effects, in turn, also reduce the frequency of introduction of vulnerabilities.
- Why build and maintain regression suites? Striking the right balance between manual and automated, and unit and integration tests can be a challenge. Bad tests waste both time and cause confusion. One test that can always be trusted is a regression based on a previously discovered bug. In these cases we know exactly what to test because we know exactly what went wrong and why and how it was unacceptable. We can't guarantee a new software release will be free of all flaws, but we can guarantee it will be free of flaws we have encountered before and created tests for.
- Why provide modern API documentation? Cybersecurity flaws can be introduced by mistakes in client programs as well. Modern API documentation frameworks help prevent these mistakes.
- Why try to focus each module on a single purpose? Simpler code is easier to test and code review, leading to fewer flaws and fewer vulnerabilities.
- Why follow team logging guidelines? When a vulnerability is found, quality log messages are the best tool to define the scope and impact of any exploit. Great log messages can provide assurance that the team's worst case fears did not happen.
- Why follow Illinois vendor risk guidelines? Interacting with vendors can introduce risks outside the control of the development and operations teams. This resource is a first step toward managing those risks.