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
- 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:
Cатсн²² (in)sесuяitу / ChrisJohnRiley 