SecReq: Security Requirements Elicitation

When I started my PhD, my goal was to help people write better requirements documents. SecReq [1-3] is one of the projects that allowed me to apply my expertise and the concepts I developed during my research. Results from SecReq did not make it into my PhD (except for the outlook), but nevertheless, this is one of the most exciting projects I did during my time in Hannover and I am proud to continue the work in this group of researchers.

My goal in SecReq is to constructively support people in writing better security requirements.

In practice, security requirements elicitation is often a big problem. Two of the main reasons are lack of requirements engineering expertise and lack of security engineering expertise in many organizations. In SecReq, my goal is to constructively support people in writing better security requirements. This support should cover raw candidate requirements in elicitation sessions, their refinement into accurate requirements documentation, and their tracing to design decisions.

For this, I reuse HeRA, the Heuristic Requirements Assistant, which is a research prototype from my PhD [5]. HeRA helps people to write better requirements, by analyzing the input (raw requirements) and criticizing on this input based on best practices and experiences. Those best practices and experiences are encoded as heuristic rules.

Applied to SecReq, these concepts help organizations to cope with lack of security / requirements engineering expertise as follows:

  1. HeRA heuristically identifies security relevant requirements.
  2. HeRA highlights those requirements and offers the user to start a wizard to refine them into security requirements.
  3. The wizard is based on two foundations: a) general expertise from the security requirements elicitation and refinement process defined in Common Criteria [4] and b) information needs defined in UMLsec, a framework for security analysis and design [6].

By this, I support the general goal of SecReq [1-3]: to assist all steps in security requirements elicitation, as well as providing mechanisms to trace security requirements from high-level security statements (security objectives) to rather secure design.

SecReq aims at bridging the gap between security best practises and the lack of security experience among developers and designers.

SecReq combines three distinctive techniques that have been integrated to meet this goal: (1) Common Criteria [4] and its underlying security requirements elicitation and refinement process, (2) the HeRA tool [5] with its security-related heuristic rules, and (3) the UMLsec tool set [6] for security analysis and design.

The SecReq Team

SecReq is driven by five researchers from industry and academia: Siv Hilde HoumbShareeful IslamJan JürjensKurt Schneider, and myself. We are still working on this topic, especially looking for empirical insights in this area.

HeRA helps domain experts to write requirements in a style that is most useful for security engineering.

Personally, I love this project, because it defines a challenging research area and allows each of us to contribute specific strength. In my case, this contribution was the heuristic and experience based support based on concepts from my PhD. This support is delivered via the HeRA tool [5]. In the context of SecReq, HeRA helps domain experts to write requirements in a style that is most useful for security engineering by automatically identifying security relevant requirements and by assisting the user to refine and trace them. I drove the implementation and empirical investigation of HeRA’s SecReq specific features (see above) and contributed the learning model as a foundation for experience management and organizational learning around security engineering [3].

Lessons Learned and Outlook

Security engineering is a challenging field. Today, good security engineering heavily relies on a scarce resource: security experts. Personally, I think that we can have most impact on security engineering in practice by helping to use this resource most effectively. Thus, I focus on optimizing the interface between domain experts and security experts. My personal approach to security engineering is based on constructing tool support and experience-centric workflows for security requirements.

From our joint work in SecReq, I want to share the following lessons learned. They might look like common sense. Still, they proved to be major advances in the SecReq project.

  • Be precise with terminology (Lesson 1): in SecReq we identify security relevant requirements (e.g. pay via credit card on webpage). These requirements should be refined into security requirements (e.g. use encryption). Security requirements themselves might be refined in security related requirements (e.g. use a public key algorithm) [2].
  • Manual classification is non-trivial (Lesson 2): During the evaluation we found that it is very hard to identify security relevant requirements. Finally, we defined a classification question that helped us in this task [2]:

Classification Question: Are you willing to spend money to ensure that the system is secure with respect to this requirement?

  • Experience can be captured based on machine learning (Lesson 3): We showed that a Bayesian classifier can be used to externalize our expertise on which requirements are security relevant.

In the long run, I would love to combine SecReq with recent research on requirements clarification patterns. More specific, it would be great to investigate and optimize the way stakeholders of software projects establish a shared understanding of their security requirements and to support communication beyond documentation.

If you have questions or suggestions concerning SecReq or security requirements elicitation in general, do not hesitate to contact me or any other member of the SecReq team. Of course we are also open for collaboration in this exciting field!

Resources

References

  1. Siv Hilde Houmb, Shareeful Islam, Eric Knauss, Jan Jürjens, and Kurt Schneider. Eliciting Security Requirements and Tracing them to Design: An Integration of Common Criteria, Heuristics, and UMLsec. Requir. Eng., 15(1):63-93, March 2010.
  2. Knauss, E.; Houmb, S.; Schneider, K.; Islam, S. & Jürjens. Supporting Requirements Engineers in Recognising Security Issues. In Proceedings of 17th Intl. Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ’11), Springer, 2011
  3. Kurt Schneider, Eric Knauss, Siv Houmb, Shareeful Islam, and Jan Jürjens. Enhancing Security Requirements Engineering by Organisational Learning. Requirements Engineering Journal (REJ), 17(1):35–56, 2012.
  4. ISO 15408:2007 Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 2, CCMB-2007-09-001, CCMB-2007-09-002 and CCMB-2007-09-003, September 2007.
  5. Eric Knauss, Daniel Lübke, and Sebastian Meyer. Feedback-Driven Requirements Engineering: The Heuristic Requirements Assistant. In 31st International Conference on Software Engineering (ICSE 2009), pages 587-590, Vancouver, Canada, 2009. Formal Tool Demonstration
  6. Jan Jürjens. Secure Systems Development with UML. Springer Academic Publishers, Heidelberg, 2005.
Advertisements

3 thoughts on “SecReq: Security Requirements Elicitation

    • Neil, thank you for the comment. This is a great idea we did not investigate so far.

      It would be a great fit into this project, though: Learning from past errors is currently only done implicitly, by feeding the experience of security experts back to requirements elicitation. A formal support during post mortem analysis or root cause analysis might be very beneficial.

      Of course, in security engineering, this has also another dimension: Your requirements might have been perfect last year. But meanwhile, the world has changed and new exploits became available. Offering support for organizational learning might be especially rewarding in this field.

      I know that you are expert about requirements engineering and open source projects. Can you point me to any project that allows to investigate these aspects?

      • I think Michaela might be better … but you can look at Firefox – SSL etc – that might have something.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s