Download Software Development Security in Complex IT

Software Development Security in
Complex IT Environments
Csaba Krasznay
CISA, CISM, CISSP, CEH
Hewlett-Packard Hungary
Introduction
• Creating secure software is a common
ambition since decades
• In the era of web based distributed systems
we can’t trust in just secure coding
• Security engineers must be the part of a
development project beside software and
test engineers
• This presentation shows the experience of
some real life projects in Hungary
NIST SP 800-64
NIST SP 800-64
NIST SP 800-64
Real-life CFT
• Government projects aim to achieve the
modern electronic public administration
• Security appears to the most important
requirement after business functionality
• Such software security requirements were
never seen before in our governmental
sector (Common Criteria EAL 4).
Difficulties in the proposal
• Don’t have previous experience in
comprehensive secure software development
• Don’t have Common Criteria knowledge
• Don’t have governmental recommendations,
laws, best practices
• Don’t have experiences with such complex,
interconnected, web service based architectures
• Don’t have “government-ready” security COTS
products
Common Criteria
• International standard for secure software
development (ISO 15408)
• Two parts:
– Functional requirements (what?)
– Assurance requirements (how?)
• Difficult to understand but a very useful approach
• More complex than Microsoft SDL or OWASP CLASP
• It has strengths and weaknesses, word-by-word
usage is not recommended in practice
Risk based design
• Risk analysis is a tough project because of:
– National secrets
– Institutional secrets
– Lack of previous experiences
• Three sources of risk analysis:
– Recommendation 28. from Public Administration
IT Board
– International publications
– Own industrial experience
Recommendation 28.
• Three impact levels on governmental operations
and assets:
– Basic:
•
•
•
•
Efficiency of operations decrease
Assets have minor deficiencies
Small financial loss
Negative impact on legal certainty
– Medium:
•
•
•
•
Efficiency of operations decrease radically
Assets have major deficiencies
Large financial loss
Very negative impact on legal certainty
Recommendation 28.
– High:
•
•
•
•
The organization is unable to fulfill its primary function
Assets are destroyed
Financial loss has effect for the national budget
The organization can’t assure legal certainty
• Organizations can choose the overall risk level
based on standard risk assessment procedures.
• Recommendation 28. has many mandatory
security countermeasures based on Common
Criteria and ISO 27002 for these levels.
Legal requirements
• Act No. LX. of 2009 about electronic public
services
• Government Decree No. 223/2009. (X. 14.)
about the security of electronic public services
• Declares
–
–
–
–
–
–
Basic security requirements
Roles and responsibilities
Institute of national security supervisor
National security audit framework
National Network Security Center
Need of ISMS in connection with electronic public
services and risk analysis
Legal requirements
–
–
–
–
–
–
–
–
–
–
–
–
–
Documentation and personnel requirements
Logging requirements
Backup and archiving requirements
Incident handling requirements
Outsourcing rules
Antivirus system requirements
Need of secure information forwarding
Rules of access and physical security
Secure maintenance
Rules of security classifications
Evaluation and certification
Special requirements for ASP-s and Central System
Basic security policies
Security vs. usability
• Security countermeasures sometimes reduce
productivity (e.g. a lost token at a rural office)
• During the risk assessment phase it is
essential to translate the meaning of risks to
business language
• In the governmental sector its easier on the
management level (national security, legal
background) but harder at employee level
(lack of IT knowledge)
Framework based development
• In practice all solutions are based on some well
known COTS products.
• Developers don’t have any effect on the security of
these business products.
• These are not “developed” but “customized” products.
• Security requirements can be achieved by
customization and integration.
• Only a few security functionality will be developed
from scratch.
• Common Criteria compliance is needed to rethink.
Secure architecture elements
• Main security functions:
– Log: world class COTS
– Authorization: business product internal function +
own development
– IAM: world class COTS + own development
– PKI: local COTS + own development
– Self protection: business product internal function +
infrastructure function
– Resource utilization: business product internal
function + infrastructure function
– Secure communication: world class network
solutions
Software design phase
• We have:
– Risk assessment (threats)
– Security environment (assumptions)
– Legal background (policies)
• We have to lay down
– Security objectives (what shall our product do?)
– Security functional requirements (how will our product work?)
– Security assurance requirements (how can developers assure
the proper functionality?)
• We have to arrange an internal security course for our
developers because they’re not aware all of these issues.
Internal security education
• Software developers are not (IT) security professionals
• Internal and external attackers used to have deep
(business) software knowledge
• Security pros have to explain administrative, logical and
physical security
• From the top (need of policies) to the bottom (secure
coding)
• 3 days training for lead developers, 1 day training for the
others
• They have to take an internal exam
Security Target
• This is the security baseline, source of all
other documents
• In CC it has a very formalized content
• We have to decide whether we follow these
requirements or not
• Its main goal is to assure consistency from
the risk assessment till testing.
Security Target
Software security architecture
• According to CC, Software security
architecture consists the method of
– Self-protection
– Domain separation
– Non-bypassability
• In practice this document explains the
Security Target in a less formal way
• Domain separation is the most important part
Functional specification
• In the CC world this is the interface specification
• Describes how security functions connect to the
other parts of the product and environment
• Interfaces are specified in terms of their
purpose, method of use, parameters, parameter
descriptions and error messages
• Can be a part of the general functional
specification
Integration issues
• Three types of interfaces:
– Well-documented, standard based
– Self-developed, internal used
– Undocumented
• In practice sometimes neither standard
based interfaces are clear and easily
adoptable
• Legacy system integration is a nightmare
Logical design
• Detailed description of security functions
• Can be the part of general logical design
• Two level of decomposition:
– Subsystem: high-level description
– Module: low-level description
• In this level security professional gives the
design project (and responsibility) to
developers
Log management
• Challenges:
– Finding a good central log management and
analysis solution that can fulfill almost every
requirements
– Measuring EPS and storage requirements
– Ensuring the “100%” availability
– Finding out an “authentic logging” solution for
forensic procedures
Identity management
• Challenges:
– Designing an identity management structure that
consists 15.000 different organizations
– Handling strange organizational relations (who
governs who and in what situation)
– Developing a huge mixed (paper-based and
electronic) identity management procedure
– Including non-conventional attributes
– Trying to avoid one-man groups
Authorization
• Challenges:
– COTS can only handle simple situations
– Adapting the authorization schemes of 15.000
organizations
– Need authorization for many objects,
procedures, persons, groups, organizations…
– Mix of MAC, DAC, RBAC…
– Implementation of four eyes principles
– Use of password based and token based
authentication even in one transaction
Cryptography
• Necessary crypto functions:
– Token-based authentication (PKCS#11)
– Automatic and manual electronic signatures
(XAdES)
– Encryption (RSA)
– Timestamp (RFC 3161)
– Integration with the Citizen Gate (Recommendation
21.)
• Solution:
– IAM integration
– Special local solution
Physical design
• This is a form that captures the detailed
internal workings of the product
• This may be language specific plans,
software source code, etc.
• Describes how security functions are
implemented in the framework
• Deep technical knowledge is required to
understand this level
Secure development environment
• According to CC (and national security), the
developer shall prove the security of its location
• Something like ISO 27000 is required
• Developer shall:
– Appoint a security officer who is responsible for the
security of the facility and assets
– Establish an IT security policy system for the facility and
assets
– Use the required countermeasures
• Security level depends on the type of the product
(restricted area, clearance levels, etc.)
Policies
IT Security Policy
IT Security Strategy
IT Security
Standards
Acceptable
use policy
Procedures, Baselines, Guidelines
Roles
Basic
Medium
High
Project leader
National security
certificate
National security
certificate
National security
certificate
Members of the
project
administration,
Security,
Development and
IT operations
officers
Certificate of No
Criminal Record
with background
check, CISM for
the Security officer
National security
certificate, CISM
for the Security
officer
National security
certificate, CISM
and classified
information
management
certificate for the
Security officer
Developers,
operators
Certificate of No
Criminal Record
Certificate of No
Criminal Record
with background
check
National security
certificate
Hardware and software
• Hardware and software assets shall reach the
same confidentiality level as in the operational
environments
• Lower level of integrity and availability is
accepted
• Explanation: development environment directly
or indirectly is used to store sensitive
information
• In secure developments the project shall count
on these costs
Configuration management system
• CM ensures the integrity of the product from
early design stages through all subsequent
maintenance efforts
• It shall provide authorization and integrity
controls
• CM procedures shall deal with security
• Good example is the software release
procedure or the need of audit trail
• Project documentation shall consist the
configuration list
Development phase
• This is the traditional part of secure software
development
• Usually requires deeper knowledge than IT
security professionals have
• During this phase we can deal with other
aspects and prepare for the next phases
Secure coding
• Secure coding is not our business
• Developers shall ensure that they use
language specific security recommendations
• If they don’t they’d fail on penetration testing
• Most frameworks support secure coding by
default (e.g. with integrated SQL injection
filter)
• Most hackers have their own method to
bypass these countermeasures…
OWASP
• www.owasp.org is a good source for all web
application security issues
• Guide to Building Secure Web Applications
and Web Services is an essential material for
all developers
• Code Review Guide is good for quality
assurance
• Testing Guide is a structured set for
penetration testers
Documentation
• Developers shall provide two types of
documents that deal with security:
– Installation guide: it consists secure configuration
of the product, a.k.a. the hardening guide
– User guide: describes how administrators can
maintain and users can use the product securely
Testing phase
• Developer shall prove that the design and
implementation steps are consistent
• The proofs are the test coverage, test depth
and functional test documentations
• Security professionals shall supervise this
phase carefully
Functional testing
• Security functional testing is the part of the
normal testing procedure
• Provides assurance that the likelihood of
undiscovered flaws is relatively small
• Includes test environment, test conditions,
test data parameters and values
• Most automatic test tools can provide the
expected test documentation
Vulnerability testing
• Decision points:
–
–
–
–
–
–
Target: application, services, system level
Elapsed time: day, week, month
Expertise: layman, proficient, expert, multiple experts
Knowledge of the product: public, restricted, sensitive, critical
Equipment: standard, specialized, bespoke, multiple bespoke
Number of samples: unlimited access, easy, moderate,
difficult, none.
– Test cases: structural (OWASP Top 10, OWASP Testing
Guide), intuitive
Evaluation and certification
• In Hungary software security evaluation and
certification doesn’t have traditions
• We only know that somebody will evaluate our
products somehow sometime.
• We have to use CC EAL3 and EAL4 levels so the
evaluation will based on Common Evaluation
Methodology
• But which version of CC?
• Nobody has real experience in CC-like development
and evaluation in Hungary
MIBÉTS
• Recommendation 25 consists the Hungarian
Information Security Evaluation and Certification
Scheme (MIBÉTS)
• This is the Hungarian version of Common Criteria
• Have experience in some minor digital signature
software projects
• Theoretically our products will get MIBÉTS
certification
• These projects will be the first real exam for MIBÉTS
Distribution
• Secure distribution is tough project to 15.000
different site
• Possible solutions:
– Through internet
– Via internal post on DVD
– Centrally organized mass installation
• Distribution of central components is easier
with the control of national security agency…
Summary
• Complex software development requires an IT security
officer who takes part in:
–
–
–
–
Requirement specification
Design
Documentation
Testing
• This role needs the knowledge of law, business
processes, software engineering, test engineering
besides traditional security
• Software security is on of the most emerging area in IT
security because coding securely is not enough
nowadays
E-mail: [email protected]
Web: www.hp.hu, www.krasznay.hu
Tel: +36 20 5349756
THANK YOU!