Security Engineering

Security Engineering By Paul McBroom

Introduction • In this presentation, we will discuss: • The need for an integrated security process. • Why there isn’t one yet. • Two suggested processes. • A process for Embedded components • A security-integrated agile process.

Why the need? • Security is usually an after-thought which leads to expensive modifications, which are more expensive and time-consuming than doing it right the first time, due to increasingly complicated code. • Customers want the product fast, but they also want it as secure as possible.

Why it isn’t done • As said before, customers want their product fast, which leads to shortcuts. • Agile processes currently do not have a security process built in.

How to Make Security Integration Happen • We need more knowledgeable security engineers. • Security Certifications have been in place to make sure these people have the basic knowledge • Only experience can further knowledge which takes time. • Colleges need to stop teaching “design for securability” • Instead, encourage students to develop processes to include security.

Note About the Following Suggestions • The following suggestions were both published in 2011 and have not been tested in industry. Hence, they are strictly theoretical as of right now.

Process for Embedded Components

The core security metamodel (CSM) defines which UML elements represent the most relevant security concepts. • The CSM is as an interface to the domain specific metamodel (DSM) • it serves as a basis for the definition and description of domain-specific security properties.

The DSM defines specific security properties that allow users to define what the requirements are and be able to relate them to appropriate elements which are in their system model. • Security Domain experts (i.e. a cryptographic expert) are the ones who define the properties and requirements as it pertains to their field.

The System Model is comprised of: • The Abstract System Model (which is a high-level definition of the system and is modeled by the Security System Engineer using the DSM) • The Design System Model (which is the transformation of the Abstract System Model using the Design Transformation process). • To include these two models into the System model, one must have a CSM and one or more DSMs. • These allow end-users to incorporate security aspects into their system design without knowing much about security.

The Process Broken Down

The SecFutorConsortium is responsible for creating, updating, and modifying the CSM when necessary.

Domain Security experts give specific knowledge according to their areas of expertise and create DSMs with this.

The Security Building Block (SSB) expert is responsible for the creation of the SSBs. • These Blocks implement the properties given by the Domain Security experts. • The SSB expert knows how to create and get the blocks to work together to form more complex systems which allows for more specific properties.

the Security System Engineer creates the system model. • This person knows the requirements (both security and non-security) that need to be achieved, and creates the system model based on these, as well as what is given by the other two layers. • In essence, this person pieces all of the specifics of the system together.

Of course, we have the security testing expert that makes sure the system passes the tests.

Remarks about the Process • This process sounds good, but requires several people. This means that small companies may not be able to do this process, due to not being able to hire all of these people.

A Security-Integrated Agile Process • A suggested agile process is a hybrid of three other security processes. • CigitalTouchpoints • Common Criteria • Microsoft Security Development Lifecycle process

The Study • 100 programmers from a business where questioned about the importance of key points of each of the three processes in regards to cost and benefits. • The results where then molded into a new process.

Source of Error • One major source of error is that none of these people knew a whole lot about security. This lack of knowledge leads to an underestimated value of the benefits of each key point of the processes.

Results • Requirement Cost Benefit • Security requirm. (T,M,CC) + + • Role Matrix (M) + + • Abuse Cases (T) + • Design requirem. (M) - - • Quality gates (M) - • Cost analyses (M) - - • Agree on definitions (CC) - - • Design Cost Benefit • Assumpt. Document. (T) + • UMLSec (CC) - • Requirem. Inspec. (CC) + • Implementation Cost Benefit • Static Code Analyses (T, M) + • Coding Rules (M) + • Security tools (M) - • Testing Cost Benefit • Test plan (T) + • Fuzzy Testing (M) - • Release Cost Benefit • External Review (T) - • Incident resp. planning (M) + • Repository improvem. (CC) +

Suggested Process • Product Owner • Requirement • Security Requirements • Role Matrix • SP Development Team • Design Implementation • Countermeasure graphs • Static Code Analyses • Assumption Documentation Coding Rules • Abuse Cases • Requirements Inspection • Release • Repository Improvement (retrospect meeting) • LSV Test Team • Testing • Dynamic analyses

Conclusion • There is a need for security-integrated processes and ideas for such are starting to come about. • The two introduced processes are good ideas, but they need further study and need to be tested to see if they hold up to what they were designed for.

Works Cited • [1] Baca, Deejan, and BengtCarlsson. “Agile Development with Security Engineering Activities.” International Conference on Software and Systems Process. (2011) p.149-158 • [2] Davis, James. “Information systems security engineering: a critical component of the systems engineering lifecycle.” ACM SIGAda Ada Letters, v.XXIVn.4. (Dec. 2004) p.13-18. • [3] Ruiz, Jose, Rajesh Harjani, and Antonio Maña. “A Security-focused Engineering Process for Systems of Embedded Components.” SD4RCS ’11. 09.4 (Sept. 2011): p. 1-9.

Questions?

Security Engineering