Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

#FIRST2011 – Security Challenges For Future Systems

Security Challenges For Future Systems

Steve Purser (ENISA)

Although a lot of things are obvious, it doesn’t mean that we’re doing them. How many people have seen a perfectly implemented intrusion detection system that rings bells all day with nobody monitoring it!

  • Effectiveness –> Doing the right thing
  • Efficiency –> Doing the thing right

These might be close to each other, but doing the wrong thing right, still doesn’t make it right! We need more effectiveness…

Who is ENISA?

The European Network & Information Security Agency (ENISA) formed in 2004

The agency supports the commission and the EU member states in the area of information security

Facilitate the exchange of information between EU institutions, the public sector and the private sector

The Trends

You have to be very careful trying to calculate future trends from historical data… especially if the data isn’t suitable. In Infosec, the data we have isn’t good enough.

Computer architectures have changed enormously in the last 20 years. From mainframe environments through to COBRA and WebServices.

These architectures are secured according to different principles

The weak point often lies in the connection between these technologies

  • De-Centralisation
  • Globalisation
    • Most IT architectures are embedded in a global environment, even if they were never designed that way
    • Users regularly switch context from intranet to Internet sessions
    • Authentication != Trust
  • Empowerment of the end user
    • More choice to the user… more freedom, at a price
    • Move towards browser based applications
    • End Users are not ready to rise to the challenge
  • Need for Speed
    • First on the market wins… security is a second thought
    • Users are beta testers
    • Products released unfinished

Scope and Requirements

An operational system is not just technology

System = Software + People + Procedures

Secure software will not always function correctly if we make unrealistic assumptions about how people behave.

The key challenge to developing secure systems is understanding and responding to the limitations of the target environment(s)

Understanding the Threats/Risks

Risk = Threat + Probability + Impact

This process isn’t a one-off… it needs to be a cyclical model, with constant review.

Functional Requirements

We can distinguish between functional and non-functional security requirements

Traditional security functional requirements are reasonably well understood

  • Confidentiality
  • Data and session integrity
  • Availability
  • Accountability
Certain requirements are more difficult
  • Which data is considered private
  • Security vs. Privacy

Non-functional Requirements

Many real-life security issues arise out or poor definition of non-functional requirements
  • Scalability
  • Operational Constraints
  • Flexibility
    • Modularity
  • Usability
If you have the best solution in the world, but it need 50 admins to keep it running… if you don’t have 50 admins, then it’s not feasible.

Software Layers

Different software layers perform different security functions
This has led to a difference between infrastructure services and application services. It’s not often that your software service performs AV checks… this is an infrastructure issue.
In the future we should strive for a closer integration. The flaws are exposed in the connection between infrastructure and application services.
The OS is the key to everything. All security relies on your OS being secure… root is king!

Evolving security models

Different IT architectures require different security models. This isn’t just about technology, but also about associates procedures.
Established architecture can’t always be modified to meet new demands. Sometimes you need to rethink the architecture to gain security.

Example:

Mainframe Architecture
We authenticate to the OS and we stay on the ‘box’
Highly Distributed Architecture
Here we need to re-authenticate
  • Relay user authentication
  • Object-to-object
  • How easy is it to implement?
  • How easy is it to manage?

New security models

As the trend towards de-centralisation continues, we will need to consider new security models
Peer-to-peer networks have no central point of control by definition. Such networks operate on the basis of distributed trust.
cloud computing puts new demands on the scalability of applications. Predicted scalability is feasible, on-demand scalability for secure applications is hard (key-management)

Some design considerations

  • Think about non-functional requirements
  • Use defense in-depth
    • Don’t rely in a single control
    • Have fallback

Methodologies

Integration of security methodologies into development methodologies is a must

Many current methodologies are essentially linear

There is the risk of not seeing the forest for the trees… what is the problem we’re trying to mitigate?

ENISAs Contributions

  • Community building
  • Policy Alignment
  • Technical Work
    • Cloud Computing
    • Secure Software Development

Conclusions

Trends in system development include increasing decentralisation, global connectivity, more empowerment of the end users and short development cycles.

The key challenge to developing secure systems is understanding and responding to the limitations of the target environment(s)

Sufficient weight should be given to non-functional security requirements

Security design should be based on architectural principles

Traditional centralised security models are being pushed to their limits – new models are emerging

End-to-end security is more important than single system security for distributed environments

Links:

Advertisements

One response to “#FIRST2011 – Security Challenges For Future Systems

  1. Pingback: #FIRST2011 – Round-up « Cатсн²² (in)sесuяitу / ChrisJohnRiley

%d bloggers like this: