secure syygstem integration methodology · 3.3. our approach for secure system integration our...

9th ICCC in Korea, 2008

Secure System Integration Secure System Integration y gy gMethodologyMethodology

Satoshi HARUYAMA, Toshiya YOSHIMURA, Naohisa ICHIHARA

NTTDATA Corporation

Copyright© 2008 NTT DATA Corporation


ContentsContents

1. BackgroundA) Issue of security in system integration) y y gB) Standardization of system integration process

2. Our goal

3 O h f t i t ti3. Our approach for secure system integrationA) Scope (system security and project security)B) Overview of system security assuranceC) Overview of project security assuranceD) Required security level

4. Apply the concept of CC to our standard process4. Apply the concept of CC to our standard process4.1 Planning Process: Definition of security requirement4.2 Development Process: Realization of security specification4 3 Operation Process: Clarification of operational condition4.3 Operation Process: Clarification of operational condition

5. Further issue

6. Conclusion

Copyright© 2008 NTT DATA Corporation- 2 -


1. Background 1. Background

Issue of security in system integration– Security is not treated as primal factor in the traditional software

engineering because;• Hard to define Security as system quality as it is sometimes

subjective, obscure and relates various aspects of system• Complicated to resolve the interference among NFRs (Security,

Performance, Efficiency, Reliability, Usability, Maintainability)

Related works– Researches; UML-sec, Security Patterns, Secure Tropos– Vendor works; Microsoft, IBM, NTTDATA, ... etc

We need effective and pragmatic methodology to assureWe need effective and pragmatic methodology to assure integrate secure system




Standardization of system integration process– Defined for improving system quality as follows:

• System life-cycle model– Process

Task– Task

• Standard process in system life-cycle model– Planning, Development, Operation process – Management process– Tailoring process




Standardization of system integration process

System life-cycle model (image)

Basic Requirements External Making Test

Planning Development

Operation

Operation

Internal

System life cycle model (image)

Planning/Development/Operation Process

Basic Investigation

Requirements Definition

ExternalDesign

Making(Programming) Integration test

System test

OperationMaintenance

InternalDesign


Task A

Task flowTask B1 Task C

Defined ・subtask・work descriptionas

monitoring/control

Task B2

work description・output・check list・・

・・・

Management Process Project Integrated

managementProject Scope

MgtProject Time

MgtQuality

MgtHuman

resources Acquisition

monitoring/control


a age e t

Cost Mgt Risk MgtCommuni

cation



Standardization of system integration process

Industry StandardSLCP JCF2007

Tailoring Process-Planning Process-Development process-Operation process-SLCP-JCF2007

-CMMI

Organization Standard ProcessTailoring

-Operation process-Management process


T k flStandard Process

Project Standard Process

Tailoring Standard

Tailoring(choice/replacetask) Management Process

Task A

Task flow

Project Integratedmanagement

Scope Time

C t

Quality Human resources

Ri kCommuni

Acquisition

monitoring/control

Task B1

Task B2

Task C

Defined ・subtask・work description・output・check list・・

・・・

Cost RiskCommuni

cation

Planning Development Operation



2. Our goal2. Our goal

Goal:– Establish the effective and pragmatic methodology

to assure security of systemto assure security of system.

• Point 1: Plan the security of system “as required”y y q– Identify the required security and its level for the system– Avoid spending security cost than needed– Agree the required security and cost with customer

• Point 2: Develop and operate securely “as planned”– Realize and maintain the security correctly as planned – CC concept based methodology which involves;p gy ;

» “Completeness”, “Consistency” as well as “Responsibility”

• Point 3: Aim to be more “commonly used” Adopted to the existing development methodology– Adopted to the existing development methodology

– Define standardized tasks to develop security for all the developers



3.3. Our approach for secure system integrationOur approach for secure system integration

Scope– We categorize two type of security related to system integration.

O ti ／

System security

A li i

Securitymanagement

Securityfunction

Security for the

System（operation）

Operation ＩＴ environmentnon IT environment

Operation／Maintenance EnvironmentApplication

Framework IT architectureSecurity for the target system (operation phase)

（operation）Admin、Operator

o e o e t

User

Project security

Security for the project that is

system（development）

Development environment

Developer

developing the target system. developmen

t




Overview of system security assurance

Basic Investigation


ExternalDesign

Making(Programming)

TestIntegration test

System test



Operation

InternalDesigng System testg

Agreement

・Check security policy, regulation standard etc

Realization

・Implement security specification Maintenance

regulation, standard etc..・Analysis security risk

・Agree with ;-security scope

and secure operation (rule, environment, procedure)・Verify (test) security level agreed with customer (in planning process)

(h

・Monitor target system operation for keeping the security level, and response security incident throughoutsecurity scope

-required security level-security requirement -total cost

・Manage project (human resources, development environment and procedure)

security incident throughout development and operation phase




Overview of project security assurance– Manage project for keeping security (a part of management process)

f llas follows:

Development security

CM capabilities (ALC_CMC)- Development documentation management

Development

p y（ALC_DVS）

-Development securitydocumentation

g

environmentshall describe all the physical, procedural, personnel, and other security measures that are

Basic Requirements External Making Test


Operation

Operation

Internal

life-cycle model

necessary to protect the confidentiality and integrity of the TOE design and implementation

Basic Investigation


ExternalDesign

Making(Programming) Integration test

System test


InternalDesign

Life-cycle definition (ALC_LCD)

-The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE

Refer to ISMS(ISO/IEC27002:2005)

“ISMS Aspects in Common Criteria


ISMS Aspects in Common Criteria Certificates for Development Sites”, Bertolt Krüger,6th ICCC 2005



Required security level (1)– CC assurance approach is efficient to provide system security assurance– However, applying CC scheme to all project is not reasonable (project cost,

time, human resource…)– Therefore, we apply the concept of “Required security level” based on

simplified CC assurance scheme to our standard processsimplified CC assurance scheme to our standard process

Required security level Planning process

S

A

high

A

low

B

C

Standard Process

Define “Required security level”

Agreement

security level

Provide simplified criteria to enable developer and customer to agree


Agreementwith customer the goal of “security level” easily



Required Security level (2)– Define tailoring rule according to “Required security level” in our standard

process– Tailoring rule (choice/replace of security task) realize CC SAR scale (Scope,

Depth, Rigour)“Required security level” correspond to “simplified EAL”– Required security level correspond to simplified EAL

R i d T k R i d S i L l

Tailoring Standard (image)

Required security level

high

Required Task Required Security Level

S A B C

Scope Lv1 (Critical subsystem)

S

A

high Lv2 (All)

Depth Lv1 (Requirement)

Lv2 (Design)

Matrix,to define

‘Required task’

low

B

C

Lv3 (Implementation)

Rigour Lv1 (Check and review)

Lv2 (Automated tool)

Required taskfrom

‘Required SecurityLevel’


Lv3 (Diagnosis by experts)


4.4. Apply the concept of CC to system integrationApply the concept of CC to system integration

Concept of CC applied to our standard process

Completeness

Consistencyy

Responsibility4.3 Clarification of operational condition

Planning Development Operation

Basic Investigation


ExternalDesign

Making(Programming)

TestIntegration test

System test

g p


p

InternalDesign

4.1 Definition of Security requirement

4.2 Realization of Security specification




4.1 Planning Process: Definition of security requirement– Clarify security scope (considering Responsibility), and solve all security y y p ( g p y) y

concerns (considering Completeness) in Planning Process (BI,RD)where we applied ST concept (definition of security scope and specification) to our standard process

ASE SPD

Security risk analysis

Security problem

TOE DescriptionASE_INT Threats Security objectives

(TOE)Security

requirements TOE summarySpecification

ASE_SPD ASE_OBJ ASE_REQ ASE_TSSdefinition

Organizational Securitypolicies

Security objectives(Operational Env)

Security Scope

Assumption

Security SpecificationSecurity Scope

Completeness:All threats are countered, all OSPs are enforced, and all

Responsibility:Is the scope definition of security exact (target threats,

Security Specification


,assumptions are upheld?policy, assumption)?



4.2 Development process: Realization of Security specification– Manage and test (verify) to realize security specification defined in Planning

process (BI RD) (considering Completeness, Consistency)process (BI,RD) (considering Completeness, Consistency)where we applied CC security assurance concept as follows:

• Manage the security specification with keeping traceability (ADV)• Test (Verify) the security specification (ATE)( y) y p ( )

Manage and test p ocess

Consistency:between documents each other and security requirement (Planning Process)Manage and test process

External Design Internal Design MakingRequirement Definition(Planning Process)

Traceability management (ADV)

Process)

SecurityObjectives SFR Functional

SpecificationDesign

DescriptionImplementationRepresentation Implementation

g g g( g )

Policy modelTOE SummarySpecification

Completeness:

Test (ATE)-Functional test (ATE_FUN)Independent test (ATE IND)


Completeness:manage and test the specification in correct coverage, depth, and rigour

-Independent test (ATE_IND)



4.3 Operation Process: Clarification of operational condition– System security requirement is satisfied by not only TOE function but

“ i t l diti ”“environmental condition”– To clarify responsibility of system development (=Responsibility), provide

“guidance document” that describe environmental conditionwhere we applied CC assurance concept ( guidance document: AGD class)where we applied CC assurance concept ( guidance document: AGD class)

Responsibility of system development

Responsibility:

Threats

Security objectives(TOE)

Security functionalrequirements

Security assurancerequirements

Responsibility:Identify and describe environmental condition sufficiently?

A i

Organizational Securitypolicies

Operational Condition Guidance document

sufficiently?

Security objectives(Operational Env)

Assumption

User operation (AGD_OPE)preparative procedure (AGD PRE)


preparative procedure (AGD_PRE)


5.Conclusion5.Conclusion

Our goal:Establish the effective and pragmatic methodology to assure integrate

secure system

Apply CC concept to our system integration standard process– Project security– System security– Concept of “Required security level” p q y

CC concept:– Completeness– Consistency– Consistency– Responsibility



6.6. Further issueFurther issue

NFR interference– Security may interfere with Performance, Usability, as well as

MaintenanceabilityMaintenanceability– When we should take into account this problem? How we could resolve or find

agreeable Quality

CostCost– Hard to estimate necessary cost for security quality (not only buying security

product, but also development costs)– How we could explain the security cost to be needed in the projectHow we could explain the security cost to be needed in the project– Low cost leads less security

OptimizationH t di id th ibilit f it b t l i l l diff t– How to divide the responsibility of security between logical layers, different developers, different players, as well as to keep balance with security, cost and other NFRs

– Concept of “Composite Evaluation Class” (in CC v3 *) may help us in the caseConcept of Composite Evaluation Class (in CC v3. ) may help us in the case of a large scale IT system development, to resolve the complexity about responsibility of security



Reference:Reference:

System integration process:– ISO/IEC 12207:2008 Systems and software engineering -- Software life cycle processes – Software Life cycle Processes-Japan Common Frame 2007 SLCP-JCF-2007Software Life cycle Processes Japan Common Frame 2007 SLCP JCF 2007– CMMI for development Version1.2– NTTDATA TERASOLUNA® Development process ver3.0

Framework related to securityy– Common Criteria Ver3.1 part1,2,3– ISO/IEC 13335-1:2004 , ISO/IEC TR 1335-5:2001 (GMITS)– ISO/IEC 27002:2005 Code of practice for information security management (ISMS)– SSE-CMM ver3.0

Security Design– Secure Systems Development with UML , Jan Jurjens– Security Patterns, (http://www.securitypatterns.org/patterns.html#2008)– Trustworthy Computing Security Development Lifecycle, Microsoft– CLASP (Comprehensive Lightweight Application Security Process), Fortify

Presentation PaperPresentation, Paper– “ISMS Aspects in Common Criteria Certificates for Development Sites”, Bertolt Krüger,6th

ICCC (2005)– “The Requirements for IT System Evaluation”, Haruki TABUCHI, 4th ICCC (2003)


q y , , ( )

secure syygstem integration methodology · 3.3. our approach for secure system integration our...

Documents