BSidesQuebec2013_fred

145 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
145
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

BSidesQuebec2013_fred

  1. 1. Software Architecture Risk Analysis (SARA): A Methodology to Assess Security Risks in Software Architectures, and an Application Fred Painchaud
  2. 2. Who Am I? Defence scientist at DRDC Valcartier In the Mission Critical Cyber Security section Group leader of Systems Protection and Countermeasures My research Software architecture risk analysis, penetration testing Fuzzing, trace analysis, taint analysis, symbolic execution, automatic exploit generation, ... 1
  3. 3. Agenda Rationale SARA main characteristics What SARA is not SARA methodology overview Selected application overview 2
  4. 4. Rationale No complete methodology found to assess security risks in software architectures Considering security during system engineering is important; doing it simply and quickly is chief Assessing the security of existing software system architectures 3
  5. 5. SARA Main Characteristics Design objectives Stay coherent with established practices Provide structure, not specific knowledge Focus on quick, scoped, repetitive and complementary assessments Emphasize participation of system architects, designers and users 4
  6. 6. What SARA Is Not A C&A methodology A silver bullet A magic wand to become a security expert 5
  7. 7. SARA Methodology Overview 6
  8. 8. SARA Methodology Overview Inputs All architectural documentation System’s lead architect or other experts and users Step 1 – System/component characterization Determine what is the next most security-critical component to analyze Develop a one-page functional overview of that component including its implemented security control mechanisms Output The selected component’s one-page functional overview, including its implemented security control mechanisms and potentially including assumptions on data coming in and going out of that component and how the data are used in the system 7
  9. 9. SARA Methodology Overview Inputs The component one-page functional overview Security experts’ knowledge about potential threats Step 2 – Threat identification Determine which threats are applicable to the component by answering: “Can this threat be used against the component?” Output Threats identified as applicable to the component 8
  10. 10. SARA Methodology Overview Threat likelihood High Low Low Control effectiveness Medium High High Medium Medium High Medium Low High Medium Low Low 9
  11. 11. SARA Methodology Overview Attack likelihood High Low High Impact magnitude Medium High High Medium Medium High Medium Low Low Medium Low Low 10
  12. 12. Selected Application Overview Component consisting of a few computers used to share information among systems of a Canadian Forces aircraft Fairly high level, considering Operating System and application versions used, but no actual code, and Standard Operating Procedures Took six weeks (a bit long), involving stakeholders and key players, such as the lead developers Targeted “low hanging fruit”: security risks that are the most obvious to spot and mitigate 11
  13. 13. Selected Application Overview Low importance risks Potential attacks necessitate very good understanding of the component architecture which makes them unlikely, very targeted attacks Data files use very simple file formats and thus their viewers are not usually vulnerable to attacks Data files and their applications are not widespread so publicly known attacks against them are scarce or inexistent (unlikely targeted attacks) 12
  14. 14. Selected Application Overview Medium importance risks The component uses image files and viewers for which there are known attacks but since the images come from DND sources, the chances that they are infected is medium and not high Many data files loaded in and produced by the component are stored unencrypted but stealing or corrupting those data files would constitute a very targeted attack and was assessed as a medium risk instead of high The component uses an FTP server with a few known vulnerabilities but that FTP server software is not a widely spread one and this risk was considered medium instead of high 13
  15. 15. Selected Application Overview High importance risks A single storage medium provides the data interface between many systems and the assessed component Only one antivirus software is used to protect a system used to load data in the component One type of user logs in as an administrator in a system used to load data in the component, even though administrative privileges are not necessary Many operating systems used by the component are out of date 14
  16. 16. Selected Application Overview Recommended mitigation plan Setup a dedicated computer equipped with multiple antivirus software to scan everything Reduce the use of removable media to the minimum; use network transfers instead Enforce minimal required privileges on all user accounts Keep Operating Systems and applications updated Determine the cost of modifying the component to work with encrypted data files 15
  17. 17. Selected Application Overview Implemented mitigations (Being studied) Setup a dedicated computer equipped with multiple antivirus software to scan everything going in (Implemented) Reduce the use of removable media to the minimum; use network transfers instead (Implemented) Enforce minimal required privileges on all user accounts (Migrating to a different, modern OS) Keep Operating Systems and applications updated (Being studied) Determine the cost of modifying the component to work with encrypted data files 16

×