software development security in complex it environments csaba krasznay cisa, cism, cissp, ceh...

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

THANK YOU!

E-mail: csaba.krasznay@hp.com

Web: www.hp.hu, www.krasznay.hu

Tel: +36 20 5349756