Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and
The policy decomposition is the process of breaking down high level policy requirements into security objectives and eventually protection needs and secure software requirements.
Policies involving protecting data could be decomposed in confidentiality requirements.
Policies involving protecting data from unauthorized alteration can be decomposed in integrity requirement.
Policies associated with determining access can be decomposed into availability requirements.
Data Classification and Categorization
Data classification is a risk management tool, with the objective to reduce the costs associated with protecting data.
Types of data :
- structured – the most common form of structured data is that stored in the DB; other forms of structured data, XML, JSON test files, log files.
- unstructured – the rest of data that is not structured; data that is not easily parsed and parsed.
Data states :
- data at rest.
- data in transit – data being transmitted from one location to another.
- date being created.
- data being changed or deleted.
Data classification/labelling is the conscious effort to assign labels (a level of sensitivity) to information (data) assets, based on potential impact to confidentiality, integrity and availability (CIA).
The main objective of data classification is to lower the cost of data protection
and maximize the return on investment when data is protected.
- Data Owner – (also called information owner or business owner) is a management employee responsible for ensuring that specific data is protected. Data owners determine data sensitivity labels and the frequency of data backup. The Data Owner is responsible for ensuring that data is protected. A user who “owns” data has read/write access to objects.
- Data Custodian – provides hands-on protection of assets such as data. They perform data backups and restoration, patch systems, configure antivirus software, etc. The Custodians follow detailed orders; they do not make critical decisions on how data is protected.
Role and user definitions
- objects – items that a user (subject) interacts with in the operation of a system.
- subjects – an active entity on a data system. Most examples of subjects involve people accessing data files. However, running computer programs are subjects as well. A Dynamic Link Library file or a Perl script that updates database files with new information is also a subject.
- actions – permitted events that a subject can perform on an associated object.
The subjects represent who, the objects represents what and actions represent the how of the subject-object-activity relationship. A subject-object matrix is used to identify allowable actions between subjects and objects based on use cases.
Once use cases are enumerated with subjects (roles) and the objects (components) are defined, a subject-object matrix can be developed. A subject-object matrix is a two-dimensional representation of roles and components.
Functional requirements describe how the software is expected to function. They begin as business requirements and are translated into functional requirements.
Uses cases are a technique for determining functional requirements in developer-friendly terms. Use case modeling is meant to model only the most significant system behavior or the most complex ones and not all of it and so should not be considered as a substitute for requirements specification documentation.
From use cases, misuse cases can be developed. Misuse cases, also known as abuse cases help identify security requirements by modeling negative scenarios.
Time of Check/Time of Use (TOCTOU) attacks are also called race conditions: an attacker attempts to alter a condition after it has been checked by the operating system, but before it is used. The term race condition comes from the idea of two events or signals that are racing to influence an activity.
Some of the common templates that can be used for use and misuse case
Requirements Traceability Matrix (RTM)
The RTM is a grid that assists the development team in tracking and managing requirements and implementation details.
A generic RTM is a table of information that lists the business requirements in the left most column, the functional requirements that address the business requirements are in the next column. Next to the functional requirements are the testing requirements. From a software assurance perspective, a generic RTM can be modified to include security requirements as well. This is a template example of RTM diagram: Requirements Traceability Matrix Template
You must be logged in to post a comment.