Thursday, 2 October 2008

Magic Quadrant and the Colour of Security

This post combines feedback from the last two sessions of the conference. The first session was an explanation of the famous Gartner "Magic Quadrant", and during this session they exploded a few myths.

Magic Quadrants

Every vendor in the diagram is a worthy alternative—it depends on what you need from the product. If you have a niche need, then a niche product may be perfectly appropriate; but don't expect that you can make a purchase decision by just looking at the diagram; furthermore, don't expect to make a decision based on looking at the diagram and reading the analysis. Instead, look at the diagram, read the analysis and then speak to an analyst—through that last process, the analyst will sometimes suggest vendors that didn't meet the criteria for inclusion in the report but are more appropriate to us than the vendors listed.

Magic quadrant diagrams are only produced for markets that have reached a certain maturity, so the inclusion of a vendor on the diagram should give us an indication not only of their place in the market, but the maturity of the market altogether. Sometimes, magic quadrant reports get combined over time as markets become less siloed and products more integrated. We need to keep an eye on acquisitions ourselves, as diagrams are not updated especially to reflect events—only yearly on a schedule.

The Colour of Security

This session took the form of a panel discussion which asked two questions:

  1. Will business systems be more or less secure in ten years time?
  2. Will there be a separate IT security function in ten years or will it have become wholly integrated into IT operations?


 

Separate IT Security Function


 

Perpetual Arms Race


 

Security Nirvana


 

No Security Function


 

Chaos


 

Software Engineering

 


 

Less Secure


 

More Secure


 

The above grid was revealed to us after the final vote. Clearly, the descriptions are for the extremes, whereas reality is likely to be less clear cut (when is reality ever clear cut?)

Perpetual Arms Race: if there remains a separate IT security organisation, more and more will move to IT operations (as they are seeing anti-virus and anti-malware moving now) but there will always be new threats to be mitigated in the future and IT security experts to mitigate them.

Chaos: if IT security organisations are operationalized and yet we are less secure, the world will descend into chaos (or at least towards chaos.

Security Nirvana: if IT security professionals maintain a separate function, but the world is more secure, then their world (and ours) will be a better place.

Software Engineering: If we end up more secure, yet there is no separate IT function, it is because we have solved the problems of IT security through software engineering.

When an American audience was asked to vote before the debates, they predicted a security nirvana; after the debate, they predicted an arms race. We, the European audience were able immediately to predict the arms race, and stuck with that prediction after the debate.

The arguments are these:

  1. IT security products are almost wholly reactive, so we will always be on the back foot—preparing for the most recently discovered hack, but never predicting the next one (and adequately defending against it).
  2. Ross Anderson (www.ross-anderson.com ) who spoke the previous day, indicated that security vulnerability in emerging technologies was virtually an economic certainty—only when markets mature, can vendors afford to get security right (look at Windows, look at the internet).
  3. Hackers are becoming professional, and are in it for the money, not the fame—that means that their priorities are different. TJ Maxxs (TK Maxxs to us) was breached months before they realised and it was even longer before their customers were told. This particular point kept me thinking—how many other institutions have been breached already and simply haven't found out yet…

Separate from my blog, I am developing a slide deck that I will post when it's ready highlighting my feedback from the conference.

Information Security Audits as an Accepted Business Support Tool at Novartis

Potemkin's villages are what you get when you announce information security audits, because people can't afford to be at the receiving end of "critical audit findings". "Audits are of little use for the management to steer a company and manage risks." No sustainability of audit preparation. People are threatened by audits, and don't see audits as risk management techniques.

  • Make the assessment selection process transparent
  • Make the conclusions transparent
  • Make it a shared decision and assessment process
  • Don't blame anybody for risks found in an assessment

Wednesday, 1 October 2008

Communities of Trust Case Studies

What we do is dependent on us being able to share data with people outside the organisation—how can we do that safely in a "community of trust"? What risks are introduced through the extended enterprise?

The greater the degree of separation, the greater the difficulty of evaluating risk. How willing is your organisation to accept risk from unmanaged PCs and non-employees?

Trust reduction factors:

  • Greater distance
  • Different organisations
  • Cultural diversity
  • Multiple jurisdictions
  • Incompatible technologies

The less you know about something, the riskier you must assume that it is.

A Community of Trust offers:

  • Assurance that you know with whom you are dealing
  • Confidence that information has not been manipulated
  • Expectation that sensitive information will not leak

Line of business decides how to use the technology that is provided by IT.

Call to action:

  • Re-evaluate your current outsourcing and partnering risks.
  • Move controls up the stack to application and data layers.
  • Put controls on endpoints where the data is used.
  • Use discretionary controls and logging and move towards mandatory controls—ultimately, automated controls.

SANS Institute Workshop: Frontline Solutions for Security Professionals

This is a longer session that all the others, and I hope will take us to a greater depth of understanding of some of the issues. The speaker is a trainer by profession, so the flavour of this posting might be different than the others. Again, SQL injection and Cross-site scripting are the two most common attacks.

The talk was longer than it needed to be (ah well) and covered much of the same ground as the other talk by the same presenter. However, he did give a demonstration of a SQL injection attack used to get passed a bank's credential logon screen, as well as a hacker's toolkit product that he recommended we use to determine what vulnerabilities our own systems might have against the black-hat use of the same techniques.


 

Security in the Age of Web 2.0

You will be exposed to Web 2.0 insecurities, no matter what.

Web 2.0: User-Centric (user as developer); distributed; open (and open source); lightweight (user friendly)

  • What makes Web 2.0 applications insecure?
  • What technologies and practices will secure Web 2.0?

Ajax, LAMP, SOAP: Lightweight. It is not the webmaster that selects content, no project manager, no network administrator, no DBA, no business analyst defining the taxonomy. Results are risky for us, and for banks, businesses…

Availability of resources—those resources that we can use to analyse our applications (SAST and DAST) can be used by attackers as well (which means it is even more important that we use them).

Openness and collaborations as a threat—deep linking, Mashups, RSS, iFrames—these things are a threat to advertising revenues (as it is main web pages that contain the advertising.

SOA as a threat—reusable services==reusable security vulnerabilities. WSDL and UDDI disclose information to hackers. Legacies in SOA are exposed to new (web) types of attacks.

SWOT for Web 2.0 Application Security

Strengths

  • Good-enough technology
  • Increasing awareness
  • Pressure from Government and regulators

Weaknesses

  • Users less mature than tools
  • No developers responsibility
  • Misconceptions about:
    • Inward facing apps
    • Role of QA separate from security assurance
    • Network security is no replacement for defence in depth

Threats

  • Dual purpose technologies
  • Changing nature of attacks (from massive to targeted)
  • Hackers industry
  • Extreme openness, collaboration

Opportunities

  • Security solutions span over application lifecycle
  • Security built into applications
  • Evolution towards Security 3.0 (application security, separate from network security)


Recommends tactical acquisition of DAST and SAST—these technologies are not likely to disappear. Check out the slide deck for the hype curve and list of vendors for DAST and SAST. Need to look into monitors and scanners for DBMS, network and application.

Do Software Composition Analysis—validate the IP of components; validate the security/functionality of patches; validate releases. Black Duck and Palamida are the vendors.

Mashups: Validate all input; examine license compliance; filter content presented to customers; formalize SLAs with third parties; expect abuse in unpredictable ways; prepare for HTML/XML screen scraping and iFrames.

Tuesday, 30 September 2008

Creating an Effective Security and Risk Management Culture

Superheroes are not here to prevent things from happening—we can't afford to be drawn to a superhero model with respect to security and risk management. The alternative is to have a mandate from the top and to earn the trust of the organisation as a whole.

The head of security must be:

  • Never considered an obstacle
  • Consulted by business
  • Someone who listens
  • Knows how the company makes money

Even better:

  • Considered an added value
  • Advice is sought out
  • Board/CEO reads report
  • Integral to IT planning

Must understand constraints on activity:

  • Regulations: External/Internal [effectiveness of rules is a function of organizational culture]
  • Cultural Proclivity [effectiveness of rules is a function of organizational culture]
  • Market Forces [if it affects the bottom line, it will automatically become a priority]
  • Technical Possibilities [functions in spite of control subject]

How many security officers does it take to make an enterprise secure? Just one… …but the enterprise must want to be secure. Awareness, Willingness, Ability. This is the natural logical progression as we bring up security awareness.

Can we come up with a form with the service catalog and get numbers for the level of confidentiality, integrity and availability they need for each of those systems? Need to make sure that data owners assess their own data criticality. Data owners explicitly accept associated risks.

Key message is that business owners own the risk, not us. They might delegate to us the actions to reduce risk, but we don't own the risk for them. Work with business owners to determine risks, and make sure they understand the residual risk that remains after we have performed agreed actions.

Sales Pitches

I have blogged something about some of the cendors at the conference, ut put it on my Sharepoint blog for the sake of security...
http://cis-netsps03.lancs.ac.uk:28921/personal/meikle/Blog/default.aspx