Are there any
Questions?
Building Secure Systems
Deepu Chandran
LDRA 1
1
Characteristics of Secure Systems
Dependable
Dependability
• Executes predictably
Trustworthiness
• Operates correctly
Trustworthiness
Survivability
• Minimal vulnerabilities that
can be exploited
• No malicious logic
Survivability
• Resists or tolerates known Secure
and novel attacks
• Quick recovery
Software
Survivability Software
Dependability Trustworthiness
(Resilience) Security
2
Standards/Organisations
• Common Criteria for Information
Common Criteria Technology Security Evaluation
IEC 62443 • Industrial Network and System Security
ISO 27001 • Information Security Management
• Information Security for Power System
IEC 62351 Control Operations (Smart Grids)
• Systems and software engineering.
IEEE 12207 Replaced MIL-STD-498
• Security techniques – Message
ISO/IEC 9797-1 Authentication Codes
3
Standards/Organisations
• Computer Emergency Response Team
CERT (CERT C and CERT Java)
CWE/CVE • Common Weakness Enumeration
OWASP • Open Web Application Security Project
• Defense Information Assurance Certification
DIACAP and Accreditation Process
• Information assurance DOD
• National Institute of Standards and Bodies
NIST • Risk management framework
• Information Technology Security
Common Criteria Evaluation
4
Embedded System Market Dynamics
Technology Trends
• Steady growth of devices connected to IP networks
• Continued miniaturization of silicon chips, coupled with decreasing
prices of components
• Wearable wireless sensors as well as in-body sensors are
expected to increase in demand over the next six years
Buyer Trends Regulatory Trends
• Demand for consumer electronics • Considerable regulatory initiatives
expected to continue increasing, for smart grid development, which
particularly in developing markets is expected to drive embedded
system adoption
• Mitigation of security risks due to
high degree of connectivity is • Energy efficiency directives
essential for market growth Embedded Telecom Sector
System
Market
Source: Grand View Research - Embedded System Market Analysis And Segment Forecasts To 2020
5
IEEE 12207
Secure by Design: (6.4.2.4 d)
• Architect, designed, and implemented to protect itself and the
information it processes
• Resist attacks
Secure by Default: (6.4.2.3)
• Design to assume security flows are present
• Default state promotes security
Secure in Deployment: (6.4.2.5)
• Deployed to be administered correctly and securely
• Securely deploy updates
Communications: (6.6)
• End user and developer channels to discover vulnerabilities
6
Where did it started … ?
Delivering Software Quality and Security through
Test, Analysis and Requirements Traceability
7
7 7
Software Security Exploits in the Wild
Prior to Windows proliferation:
1971; Creeper Virus
1987; Jerusalem Virus
1988; Morris Worm
Post Windows proliferation:
1995; Concept Virus
2000; ILOVEYOU worm
2002; Beast Trojan Horse
2010; Stuxnet
2014; Heartbleed
8
Tracking Security Vulnerabilities &
Exposures
• CVE database
• NIST National Vulnerability Database
Repositories • Open Source Vulnerability Database
of Information • SANS Institutes’ Top 20 list
• OWASP Top 10
Repositories • CERT C coding standard
• CWE database
of • ISO/IEC JTC1/SC22/WG14 C Secure
Weaknesses Coding Rules study group
9
Pervasive Problems
Input Validation
Buffer Overflows
Data Type Overflows
SQL Injection
Errors and Exceptions
10
Understanding Quality and Security
Software Software
Security quality
Reliability Security Safety Security
Processes Processes Critical Critical
Thinking Safety vs Security
• Does the application perform reliably as designed?
• Is the application resistant to external attacks
Failing Functionality vs Attack Surface
11
Applicability in Embedded Systems
Delivering Software Quality and Security through
Test, Analysis and Requirements Traceability
12
12 12
Building Security into the SDLC
Acceptance
Requirements
Testing
System
System Design
Testing
Architecture Integration
Design Testing
Module Design Unit Testing
Coding
13
Build in - Security from Requirements
Delivering Software Quality and Security through
Test, Analysis and Requirements Traceability
14
14 14
Building Security into the SDLC
Acceptance
Requirements Testing
System
System Design
Testing
Architecture Integration
g
Design Testing
Security starts with Requirements
- Security feature defined
- Assurance activities defined
Module DesignUnit Testing
Coding
15
Building In Security ..
Security Risk Assessment Drives Priorities
• Acceptable risk
• Value of the asset
• Level of protection
• Capabilities of the adversary
Tried and Tested Practices
• Understand security analysis and penetration
• Harden and assess an environment
• Role-based access in an embedded environment
• Understand networking related vulnerabilities
• Ongoing security vulnerabilities
Variety within the Embedded Space
16
Security in Design
Delivering Software Quality and Security through
Test, Analysis and Requirements Traceability
17
17 17
Building Security into the SDLC
Acceptance
A cceptance
Requirements
R equirements risk with a secure system & architecture design
Manage Testing
T esting
System System
Design Testing
Architecture Integration
Design Testing
Module
Unit Testing
U
Design
Coding
18
Security by Design
Multiple Independent Levels of Security (MILS)
Architecture
• Multiple Software Components must be segregated
• Minimize Security Vulnerabilities
• Software is developed as per Common Criteria Guidelines
Partition 3
Partition 1
Partition 2
Security
Security
Security
Middleware Middleware Middleware
Microkernel
Microprocessor
19
MILS Architecture
Separation Independent
Run trusted and Evaluation of
trustworthy Controlled Flow of security
components together
Information components and
trusted
composition
20
Security in Communication
Non Reliance of
Encryption
untrusted Inputs
Encrypt data
before sending Validate inputs
out
21
Code Reviews – Secure Coding
Delivering Software Quality and Security through
Test, Analysis and Requirements Traceability
22
22 22
Building Security into the SDLC
Acceptance
Requirements
Testing
Greatest ROI
yStatic
System
S stem D
st Analysis
esign used during implementation
Design yshelps:
System
Sy te
em
- Identify potential vulnerabilities Testing
T esting
- Eliminate latent errors
- Creation of software that is easy to verify
Architecture
Ar
Archit
hitecture IIntegration
ntegration
on
Design Testing
Module DesignUnit Testing
Coding
23
Automating Secure Standards Adherence
24
MITRE CWE and CVE
CWE Drivers
MITRE not-for-Profit organization runs multiple
Federally funded R&D Centers
Co-sponsored by Cybersecurity and
Communications
Common Community developed dictionary of software weakness types
Weakness
Enumeration Provides a unified measurable set of software weaknesses
Gives a standard for software tools and services target for
software security
Foundation for understanding and management of weaknesses
related to design and architecture
source: https://cwe.mitre.org/
25
CWE Architecture, Risk Mitigation to Coding
Standards
26
Coding Standards Model Compliance
with Tools
27
Test for Security Requirements
Delivering Software Quality and Security through
Test, Analysis and Requirements Traceability
28
28 28
Building Security into the SDLC
Acceptance
Requirements
Testing
Security-related Software Testing involves:
System
S yst
stem D
- FunctionalDesign
eSecurity
sign Testing System
- Risk-Based Security Testing Testing
Architecture Integration
Design Testing
Unit
Module Design
sign
Testing
Coding
29
Typical Decomposition within DOORS
30
Traceability Throughout the Lifecycle
Traceability from high system requirements through lower
level requirements, code, and tests ensures that requirements
are properly implemented and verified
Essential for reliability and ensures security requirements are
properly implemented and verified
31
Developing, Executing, and Reviewing
Tests
32
Returning Data Back to DOORS
33
What is Structural Coverage?
• How effectively did tests exercise code?
• Exercised, entry points, statements,
Measurement branches, compound conditionals,
execution paths
of Test • Systems requirement reliability levels up
Effectiveness with one defect per 109 operating hours
• Metric that helps determine when a
system is adequately tested
• DO-178 B/C DO-278(A) for
Structural Commercial/Defense avionics and ground
systems
Coverage is • IEC 61508 for industrial controls
• ISO 26262 for automotive
often • IEC 62304 for medical devices
• EN 50128 for rail
mandated • Company based standards (in-house)
34
Types of Coverage
Depending on the SIL or DAL level and functional
safety standard being followed, coverage
requirements and required methodology varies
• Statement Coverage
• Branch Decision Coverage
• Modified Condition / Decision Coverage (MC/DC)
• Data Coupling and Control Coupling Coverage
• Object Code Coverage
• Linear Code Sequence And Jump Coverage –
Test Path (LCSAJ)
35
Visualising Structural Coverage
Statement and Branch Coverage as Viewed Within a Flow graph
36
Visualising Structural Coverage
37
Modified Condition / Decision Coverage
MC/DC is a coverage measurement for multiple condition decisions. It
does not require every possible combination to be executed
If n is the number of conditions, then a minimum of n + 1 combinations are
required to achieve 100% coverage, as opposed to 2n total combinations
This only really comes into its own for 4 or more conditions as the
number of combinations increases exponentially
Conditions MC/DC BCCC
Combinations Combinations
2 3 4
4 5 16
12 13 4096
20 21 1048576
38
CWE Structural Coverage
39
Test Effectiveness and Software Security
Requirements Design Implementation
on Unit Test System Test Deployment
Requirements based
testing is necessary to
ensure security
• Structural coverage lets us
know if the software has been
tested (Test Effectiveness)
• Structural coverage against
requirements based test
expose poor requirements, test,
and implementation
• Different levels of coverage
• Statement, Branch, MC/DC
• Integration with targets
40
Robustness Testing
41
Robustness Testing Practices
42
Building Your Secure Products
Selecting the correct standard
• Ensuring industry credibility
• Utilising existing industry expertise in identifying known security
vulnerabilities around specific technologies and industries
Building security into each stage of the lifecycle
• Authoring, implementing, and verifying security requirements
• Utilising static and dynamic analysis, much like the way
quality/reliability is added in functional safety standards
• Applying secure coding standards
Continuing good security practices through deployment
and incremental releases
43
Are there any
Questions?
44
For further information:
www.ldra.com [email protected]
@ldra_technology LDRA Software Technology LDRA Limited
45
