Secure Programming Exam Blueprints
SANS has developed detailed blueprints for each of the secure programming assessments and certification exams. The blueprints provide information regarding the relevant job tasks and other details about the knowledge required to improve secure programming skills and perform well on any of the assessments/exams.
Blueprints for the Exams
The first question that programmers ask about the new skills assessment program is "What will be on the test?"
The answer is contained in test blueprints that detail:
- The tasks that secure programmers must be able to do
- The coding rules that secure programmers follow to carry out those tasks.
- The vulnerabilities that arise when a programmer fails to follow the rules.
These blueprints are living documents and will be updated often. They will also serve as guides to college faculty and other course developers who seek to create courses that will help programmers master secure coding in each language.
Here's an example of one small section of the C blueprint.
|
Task 1: C programmers must be able to interact securely with the environment. Programs must read input from the environment and properly validate and process these inputs, such as command line arguments, environment variables, and input streams. Programs must also be able to invoke external programs in a secure fashion. |
|
01.1.1 Input Validation: The programmer must securely process inputs from all aspects of the environment, then correctly decode, canonicalize, and validate those inputs. |
|
STUDY GUIDE: All input sources must be identified, including command line arguments, environment variables, files, sockets, and other input streams. Create full specifications for all data from untrusted sources, and validate that data against those specifications. Use the strongest form of input validation possible for your program, for example, indirect selection from a menu of choices that maps those choices to program-controlled values. Assume that your client can be spoofed or modified in a client/server or three-tiered architecture. Reject all input that is too short or too long for the program. Set and enforce reasonable range restrictions. Reject all numeric input that is below the minimum valid value or above the maximum valid value. Ensure that all inputs are of the expected data type and are syntactically and semantically valid. Treat all environmental variables with suspicion. Do not make assumptions about the size or value of an environment variable. Convert all input into canonical forms, and validate input after the input has been converted (including appropriate decoding). This applies to pathnames and filenames as well as URLs and other input strings that contain character sequences that can be subsequently converted to other sequences. Ensure that each input is only decoded once. |
|
COMMON VULNERABILITIES AND ATTACKS: Buffer Overflow, Path Traversal, Canonicalization Error, Spoofing, Missing XML Validation. |