Complex IT Environments

greenpepperwhinnySecurity

Nov 3, 2013 (3 years and 9 months ago)

88 views

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