Description of Services: SQS will perform threat modeling and security architecture reviews. The tasks will be based upon clients methodologies and requirements in order to conduct said reviews.
Threat modelling is a structured approach for analyzing the security of an application and enables the identification and quantification of security risks associated with applications or solutions. Threat modelling is typically performed early within the SDLC with its purpose being to identify threats and potential vulnerabilities within an application through the review of application design and specification documentation to identify controls for inclusion as security requirements in the development of the application.
Our approach to Threat Modelling is modularized and iterative which enables it to be used within Waterfall and Agile development approaches. This is to allow for elements of the Threat Modelling process to be performed as the supporting information for the application becomes available.
Our standard Threat Modelling Process contains the following steps:
• Understand and Modelling the Application
? Determine the Security Objectives of the Information/Application
? Identify the Information Data Flows
? Identify the User Roles
? Identify the Trust Boundaries
? Identify Entry and Exit Points
? Identify Authentication and Authorization Decision Points
? Identify Threats
• Develop Security User Stories or Abuse Cases
? Use STRIDE or DREAD as appropriate to rank threats
? Identify Potential Controls
? Develop risk mitigation strategy
Each of the above steps are documented as they are carried out and the resulting document is the threat model for the application which can be used to support design decisions
Security Architecture and Design Review
A Security Architecture and Design Review (SADR) is a structured method for reviewing the security of a system architecture at multiple levels and provide practical remediation actions to ensure maximum system security. This is performed throughout the design and implementation of a system comprised of multiple computer systems interconnected via a network.
SQS performs SADR’s to ensure that the underlying infrastructure of specific systems are secure. This includes three levels of analysis each intended to address security from the logical almost ethereal level all the way down to the hardware level.
Security Requirements Assessment
A Security Requirements Assessment is performed to ensure the system adheres to the security requirements put forth in the early stages of system development. It is intended to ensure there are no glaring security gaps in the design of the system. To perform a Security Requirements Assessment, SQS will require information such as architecture diagrams and documentation describing the intended workflow of a system, as well as the roles of its users. The following are the three key phases that will be conducted during the Security Requirements Assessment.
Security Requirements and Design Documentation
SQS will require any and all documentation pertaining to the requirements and design of the Page 3 of7
system. This includes, but is not limited to:
• Use case documentation
• Technical specifications
• Developer notes
• Administration and user manuals
• Deployment and maintenance manuals
• Network diagrams
• Existing Data Flow Diagrams
• System design diagrams
• Interconnections within the system
• Connections with external systems and networks
• Data storage mechanisms
Interview stakeholders and developers
In order to cover the gap in the available information and put the existing documentation in context, SQS will interview all of the project stake holders as well as available project managers and a small sampling of developers. All questions are derived from the existing information and should be answered honestly to the best of the interviewed ability. Contradictions and inconsistencies will only lengthen the process and might require re-interviewing. The estimated timeframe for this phase is dependent upon the number of personnel required to be interviewed. Ideally this step only requires a couple of days to achieve.
SQS security architects will collate, normalize and analyze the compiled information.
Infrastructure Configuration Review
An Infrastructure Configuration Review is performed in order to maximize the security of the physical system. This process utilizes the results of the Security Requirements Assessment to guide SQS security architects in the review of physical configurations of the target system(s).
System documentation and network diagrams
SQS security architects will require any and all documentation pertaining to the hardware and software used to make up the physical system. This includes, but is not limited to:
? Administration and user manuals
? Network diagrams
? Interconnections within the system
? Connections with external systems and networks
Interview stakeholders and administrators
In order to cover the gap in the available information and put the existing documentation in context, SQS will interview all of the network stake holders as well as available system administrators. All questions are derived from the existing information and should be answered honestly to the best of the interviewed ability. Contradictions and inconsistencies will only lengthen the process and might require re-interviewing.
Individual system configurations
In order to provide a detailed and in depth review of not only the entire system but of the individual components of the system, detailed configuration descriptions or actual configuration files are required for every piece of hardware and software used in the system. Each of these configurations will be reviewed in detail against the existing security requirements, industry Page 4 of 7
standards and best practices.
SQS security architects will analyze the documentation and configuration files provided. Each of the configurations will be reviewed in detail against the existing security requirements, industry standards and best practices. SQS uses various configuration guides, checklists and standards published by NIST, SANS and other reputable security organizations to perform the review.
Infrastructure Penetration Test
This is the last step in the SADR and is intended to leverage the customer network in certain real life scenarios based on the information gathered in the previous steps. This provides additional evidence for a customer that the system(s) can withstand an attack from both internal and external adversaries.
At this point in the SADR a wealth of information has been gathered on the target system(s). As Infrastructure Penetration Tests are frequently performed on live deployments, a scope will be defined. The scope identifies the systems that are to be tested as well as limits on types of tests to be performed. If applicable, SQS will review architecture diagram, placement of servers, network segregation, and VLAN usage, etc.
The exact scope of a penetration test is agreed during the planning and initiation phase but in general the aims of each penetration test will be to assess the security of internal and external infrastructure and to provide assurance over the security configuration of the in-scope systems. In some cases, the penetration phase will provide access to previously inaccessible hosts or networks, and in these cases, the test team will move on to test the newly-visible infrastructure, beginning again with the network mapping phase. In this sense, the sequence of test execution can become recursive. At all times, the test team will take care to avoid infrastructure that is out of scope, and will not exploit vulnerabilities that may have adverse effects on live services without prior consultation with the designated technical contact.
1. Public Information Discovery
2. Public-Facing Address Confirmation
3. Network Mapping Phase
4. Vulnerability Mapping Phase
5. Penetration Phase
SQS will then attempt to gain access to CLIENT’s network by leveraging the vulnerabilities and weaknesses discovered to a point where we are in a position to compromise information or the integrity of your network. SQS may use vulnerability scanning tools to scan the target network and systems with all its varying configurations of hardware and software, but while these scanners can perform the bulk of the scanning, manual verification is necessary to eliminate false positives, expand the scope, and to discover the data flow in and out of the network. Manual testing refers to a person or persons at the computer using creativity, experience, and ingenuity to test the target network in view of penetrating the network using SQS’ own techniques.
Manual verification is carried out using combinations of the tools listed previously, in addition to proprietary tools and simple clients such as those for Terminal Services, HTTP servers, MS-SQL, CIFS file shares, NFS exports, NIS, LDAP servers. Network configuration issues are not normally exploited as this can lead to network failure. However, should exploitation be desired, this is accomplished using tools such as Zebra and hping.
Exploitation of common host-based vulnerabilities is facilitated by the use of frameworks such as metasploit and canvas, whilst on-host data gathering is achieved by tools such as cachedump, lsadump and pwdump in conjunction with proprietary tools that are essentially batch files or shell scripts wrapping system tools such as the Windows net command and standard UNIX shell utilities. These techniques are considered aggressive, and will not be used on hosts providing live services without the permission of the technical contact.
SQS will provide the following deliverables to CLIENT:
? Weekly status updates
? Preliminary report
? Final report