Cips 2016 0309

Download as pdf or txt
Download as pdf or txt
You are on page 1of 45

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 info@ldra.com

@ldra_technology LDRA Software Technology LDRA Limited

45

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy