software development security in complex it environments csaba krasznay cisa, cism, cissp, ceh...
TRANSCRIPT
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
