http://www.theaustralian.com.au/australian-it/acs-to-unveil-professional-indemnity-scheme/story-e6frgakx-1225795650081
Thoughts anyone?
- J.
Tuesday, November 17, 2009
Social Network Security
I read this article the other day and I think anyone who is a parent will admit that this is your worst nightmare.
There's a stack of good resources on social security so I won't reinvent the wheel. That said I will provide some good resources. This stuff, I might add is good for any security professional. Whether you get random requests from friends and relatives, from the perspectives of a concerned parent or even just some of the dangers social networks pose to enterprise environments, I recommend you take a read.
Here is a summary of the attack types we are seeing:
Parents need to consider everything from where is the computer placed in the home, what are the ground rules on Internet usage, educating their kids on how to build/manage their identity online and extent the rules of stranger danger to the Internet.
For individuals, consider just who do you really want in your social network, what sort of information should they have access to, just how much do you want to blur the lines between professional contacts and personal contacts. Also, make full use of the privacy settings so that the principle of least privilege still applies (e.g. On Facebook you can create multiple groups and assign varying levels of privacy rights to them). Also you really be wary about who you let into your life and just how much information you share.
I know this all sounds like common sense stuff but if it really were all common sense, we'd be out of a job.
- J.
PS: If friends or family ask for how to securely setup Facebook I suggest this link which has some good advice and guidance.
There's a stack of good resources on social security so I won't reinvent the wheel. That said I will provide some good resources. This stuff, I might add is good for any security professional. Whether you get random requests from friends and relatives, from the perspectives of a concerned parent or even just some of the dangers social networks pose to enterprise environments, I recommend you take a read.
- http://www.us-cert.gov/cas/tips/ST06-003.html
- http://www.csoonline.com/article/496314/Seven_Deadly_Sins_of_Social_Networking_Security?page=1
- http://www.crn.com/security/208401887
- http://www.netalert.gov.au/
Here is a summary of the attack types we are seeing:
- People using social networks to connect to potentially violent rapists or pedophiles.
- Attackers exploiting a victim's known location (see again here).
- Cyber bullying.
- Stalking.
- Targeted phishing attacks.
Parents need to consider everything from where is the computer placed in the home, what are the ground rules on Internet usage, educating their kids on how to build/manage their identity online and extent the rules of stranger danger to the Internet.
For individuals, consider just who do you really want in your social network, what sort of information should they have access to, just how much do you want to blur the lines between professional contacts and personal contacts. Also, make full use of the privacy settings so that the principle of least privilege still applies (e.g. On Facebook you can create multiple groups and assign varying levels of privacy rights to them). Also you really be wary about who you let into your life and just how much information you share.
I know this all sounds like common sense stuff but if it really were all common sense, we'd be out of a job.
- J.
PS: If friends or family ask for how to securely setup Facebook I suggest this link which has some good advice and guidance.
Looks like I'll be speaking at AusCERT
Hi again,
Just a quick update, I'm about to start working on a presentation for AusCERT in 2010. I have a couple of ideas for talks that I think would be of interest to a few people - both security professionals and those that are security conscious.
Given that I now work for a vendor (don't hold that against me!) that is a major sponsor, whether I apply through the normal submission process or use our vendor slot, I don't know for sure but I can say that there's a good change that I will be presenting at the next AusCERT.
(The other reason I make this post is so that I back myself into a corner conveniently and I don't let myself get out easy if I get strapped for time or too busy with other commitmetns. So if you read this, don't let me off the hook!).
- J.
Just a quick update, I'm about to start working on a presentation for AusCERT in 2010. I have a couple of ideas for talks that I think would be of interest to a few people - both security professionals and those that are security conscious.
Given that I now work for a vendor (don't hold that against me!) that is a major sponsor, whether I apply through the normal submission process or use our vendor slot, I don't know for sure but I can say that there's a good change that I will be presenting at the next AusCERT.
(The other reason I make this post is so that I back myself into a corner conveniently and I don't let myself get out easy if I get strapped for time or too busy with other commitmetns. So if you read this, don't let me off the hook!).
- J.
Thursday, October 29, 2009
Book Review: Security Metrics: Replacing Fear, Uncertainty and Doubt
As promised here is my review of 'Security Metrics: Replacing Fear, Uncertainty and Doubt' by Andrew Jacquith.
--
Firstly, to put this book into perspective -
This book was written by someone who is an information security veteran with, by my estimation, over ten years experience. This individual is a student of multiple fields and disciplines has been involved in everything from penetration testing to programming, business analysis, project management, communications and consulting.
My impression was that at the author's core, he is an analyst - first and foremost (and this is reflected in the first sentence of Chapter 1). He takes great pride at being able to understand not just security but business as a whole and being able to convey relevant information to all people at any level and across all levels of business and verticals.
With that statement in mind, I will proceed with the review.
The book is split into eight chapters, with a summary at the end of each, covering concisely what the chapter covered.
To paraphrase what he wrote in fewer words (and here's my hoping I do not do him any injustice) he believes that risk management as it stands today is far too immature for the average security practictioner because it fails to adequately measure "true" risk. He talks about risk management as it stands today being a dead art. I think what he means to say was that "as it stands" it is, well, dead. We cannot improve what we cannot measure - let alone hope to understand. And since current risk management practises are well and truly inadequate in this regard, he says we cannot accurate assesss risk. This book is intended to come up ways and methods of devising metrics of your own.
These metrics can be used to better measure risk and this could be for something as simple as reporting to your inline manager or as a business driver to improve security across the organisation (which is the goal I would assume of any security practitioner). But the end game all about measurement.
This chapter focuses on where organisations typically sit during this process. The book spells out how information security is typically managed (read: poorly) with minimal measurable, meaningul results. Vendor promises a product to solve everything. Client buys product. Client panicks at the information cleaned. Client proceeds to fix those problems. Hope problems go away (until new lot of problems or type of problems appear). He refers to this as the "Hamster Wheel of Pain" - aka "detect-fix-patch-pray". He explains that having meaningful metrics means that you never rely on vague notions of perceived risk or a vendor promises for enhanced security. In other words, enables you to escape the "Hamster Wheel of Pain".
'Chapter 2: Defining Security Metrics'
This was arguably one of my favorite chapters. Maybe it is the analyst style hats I've worn over the years but what I really took away from this chapter was the following:
Chapter 3: Diagnosing Problems and Measuring Technical Security
This chapter focused heavily on how building a series of metrics can be used to diagnose problems within your environment. Andrew is complete in his coverage of the different categories of problems: perimeter and security threats, coverage and control, availability and reliability and finally, application security. What I enjoyed about this chapter was how he walked through the process of how you begin to analyse an environment, devise a hypothesis and then build your metrics around testing that hypothesis. In my mind, Chapter 2 and 3 read as if they were one chapter to me, it was so seamless.
(Admittedly the whole book did, but these two chapters in particular).
Chapter 4: Measuring Program Effectiveness
This chapter examines the COBIT, ITIL and ISO17799 frameworks and how they can be leveraged to help define metrics that can shed light as to how you can create meaningful measures of the degree of success in your application of these frameworks. Again, Andrew's examples show his application of how metrics can be created and applied to simple but powerful, well thought out questions.
Again, Andrew takes another swipe at ALE and asset valuation as a process. But what I liked was that while Andrew made clear his position he was able to present an opposing view - and at the same time make it no less valid than his own. It is rare in this day and age to find reference books that are capable of doing this. Most seem to present then own ideas or framework as gospel. Andrew is very conscious in his writing not to make this error.
Chapter 5: Analysis Techniques, focuses largely on the methods of how one can use the numbers gathered to gain insight. This chapter covers basic statistics and mathematics (but nothing too complicated) and how you can use means, averages, standard deviations, group and aggregation, as well as time series and cross sectional analysis, etc, across your data sets. He walks the reader through each of these methods, explaining how and where to apply them.
Chapter 6: Visualisation walks the reader through the different types of graphs and charting, explaining the common mistakes (which I grimaced as I read, knowing I was all too guilty of some of them) and providing guidance on how to construct models that are not only more meaningful but asthetically pleasing and easier to absorb.
(This actually reminded me to earmark 'Applied Security Visualisations' for future reading btw - which has also come to me as highly recommended).
In 'Chapter 7: Automating Metrics Calculations', Jacquith recovers old territory. Earlier in the book he makes specific reference to how metrics must be automated (not just for the person doing the reporting but to ensure accuracy and consistency in the results). This chapter focuses more on the benefits of automation as well as providing guidance on how and where some of the data we are after can be gathered to build and measure our newfound metrics. The previous chapters explained a lot of the theory behind building metrics. This chapter is how you put it together and provides ideas on how you can automate the process, providing suggestions of various technologies than can facilitate.
'Chapter 8: Designing Security Scorecards' focuses on building a scoring system that combines security metrics but relates them back to core business objectives. The key purpose here is to ensure the metrics are relevant to the business and can be absorbed by them. He explains that this is a framework he has used (remember: framework like ISO17799, ITIL, COBIT) and is very clear that there are limitations. I have to admit, despite the nice correlary back to the business, I did not like this format but that is a personal issue. I'm sure others will rave about it.
Earlier on, he made a good point about how metrics should be evenly applied across multiple businesses and verticals. I think that is what he was trying to was create - a framework that would enable us to do precisely that. Unfortunately the metrics you need to create to populate the card are so unique to a given environment, that the framework provided seems like a moot point to me.
At the end of the day however, I think the true purpose was to demonstrate how one would evaluate security in an organisation, define a series of metrics and use those metrics to report on the state of security back to the organisation. In other words, how to apply the lessons in this book from start to finish. In that respect, I think he succeeded.
If I have to pick one gripe (and I admit I am nitpicking here), it would be that the Summary at the end of each chapter is largely a condensed copy of the entire chapter, often using entire slabs of text. When he covers a large chunk of material in a given chapter (e.g. Chapter 6) you feel grateful, but for others (e.g. Chapter 8) it feels redundant. I would have preferred to see less redundant language in the summaries, perhaps keeping them to bullet points if he wanted to use the same text. But again, that is just a personal preference. I expect many reader's will truly appreciate the detailed summaries.
Overall, I think this book is mandatory reading for security managers, consultants (especially those who assess and audit Technical Security Controls), security architects, and even operations folk who are looking to explain/justify their existence (or find themselves in the position where they have to continually do so) or even just gain management support to their efforts.
Too many security people say they are "too busy" to deal with report writing and measuring. I think this book creates a compelling case why we need to start thinking about security metrics more - and start today.
Rating: 9.5/10
--
Firstly, to put this book into perspective -
This book was written by someone who is an information security veteran with, by my estimation, over ten years experience. This individual is a student of multiple fields and disciplines has been involved in everything from penetration testing to programming, business analysis, project management, communications and consulting.
My impression was that at the author's core, he is an analyst - first and foremost (and this is reflected in the first sentence of Chapter 1). He takes great pride at being able to understand not just security but business as a whole and being able to convey relevant information to all people at any level and across all levels of business and verticals.
With that statement in mind, I will proceed with the review.
The book is split into eight chapters, with a summary at the end of each, covering concisely what the chapter covered.
To paraphrase what he wrote in fewer words (and here's my hoping I do not do him any injustice) he believes that risk management as it stands today is far too immature for the average security practictioner because it fails to adequately measure "true" risk. He talks about risk management as it stands today being a dead art. I think what he means to say was that "as it stands" it is, well, dead. We cannot improve what we cannot measure - let alone hope to understand. And since current risk management practises are well and truly inadequate in this regard, he says we cannot accurate assesss risk. This book is intended to come up ways and methods of devising metrics of your own.
These metrics can be used to better measure risk and this could be for something as simple as reporting to your inline manager or as a business driver to improve security across the organisation (which is the goal I would assume of any security practitioner). But the end game all about measurement.
- Foreword
- Preface
- Acknowledgments
- About the Author
- Chapter 1 Introduction: Escaping the Hamster Wheel of Pain
- Chapter 2 Defining Security Metrics
- Chapter 3 Diagnosing Problems and Measuring Technical Security
- Chapter 4 Measuring Program Effectiveness
- Chapter 5 Analysis Techniques
- Chapter 6 Visualization
- Chapter 7 Automating Metrics Calculations
- Chapter 8 Designing Security Scorecards
- Index
This chapter focuses on where organisations typically sit during this process. The book spells out how information security is typically managed (read: poorly) with minimal measurable, meaningul results. Vendor promises a product to solve everything. Client buys product. Client panicks at the information cleaned. Client proceeds to fix those problems. Hope problems go away (until new lot of problems or type of problems appear). He refers to this as the "Hamster Wheel of Pain" - aka "detect-fix-patch-pray". He explains that having meaningful metrics means that you never rely on vague notions of perceived risk or a vendor promises for enhanced security. In other words, enables you to escape the "Hamster Wheel of Pain".
'Chapter 2: Defining Security Metrics'
This was arguably one of my favorite chapters. Maybe it is the analyst style hats I've worn over the years but what I really took away from this chapter was the following:
- What makes a 'good' metric.
- What makes a 'bad' metric.
- How do you measure improvement over the years.
Chapter 3: Diagnosing Problems and Measuring Technical Security
This chapter focused heavily on how building a series of metrics can be used to diagnose problems within your environment. Andrew is complete in his coverage of the different categories of problems: perimeter and security threats, coverage and control, availability and reliability and finally, application security. What I enjoyed about this chapter was how he walked through the process of how you begin to analyse an environment, devise a hypothesis and then build your metrics around testing that hypothesis. In my mind, Chapter 2 and 3 read as if they were one chapter to me, it was so seamless.
(Admittedly the whole book did, but these two chapters in particular).
Chapter 4: Measuring Program Effectiveness
This chapter examines the COBIT, ITIL and ISO17799 frameworks and how they can be leveraged to help define metrics that can shed light as to how you can create meaningful measures of the degree of success in your application of these frameworks. Again, Andrew's examples show his application of how metrics can be created and applied to simple but powerful, well thought out questions.
Again, Andrew takes another swipe at ALE and asset valuation as a process. But what I liked was that while Andrew made clear his position he was able to present an opposing view - and at the same time make it no less valid than his own. It is rare in this day and age to find reference books that are capable of doing this. Most seem to present then own ideas or framework as gospel. Andrew is very conscious in his writing not to make this error.
Chapter 5: Analysis Techniques, focuses largely on the methods of how one can use the numbers gathered to gain insight. This chapter covers basic statistics and mathematics (but nothing too complicated) and how you can use means, averages, standard deviations, group and aggregation, as well as time series and cross sectional analysis, etc, across your data sets. He walks the reader through each of these methods, explaining how and where to apply them.
Chapter 6: Visualisation walks the reader through the different types of graphs and charting, explaining the common mistakes (which I grimaced as I read, knowing I was all too guilty of some of them) and providing guidance on how to construct models that are not only more meaningful but asthetically pleasing and easier to absorb.
(This actually reminded me to earmark 'Applied Security Visualisations' for future reading btw - which has also come to me as highly recommended).
In 'Chapter 7: Automating Metrics Calculations', Jacquith recovers old territory. Earlier in the book he makes specific reference to how metrics must be automated (not just for the person doing the reporting but to ensure accuracy and consistency in the results). This chapter focuses more on the benefits of automation as well as providing guidance on how and where some of the data we are after can be gathered to build and measure our newfound metrics. The previous chapters explained a lot of the theory behind building metrics. This chapter is how you put it together and provides ideas on how you can automate the process, providing suggestions of various technologies than can facilitate.
'Chapter 8: Designing Security Scorecards' focuses on building a scoring system that combines security metrics but relates them back to core business objectives. The key purpose here is to ensure the metrics are relevant to the business and can be absorbed by them. He explains that this is a framework he has used (remember: framework like ISO17799, ITIL, COBIT) and is very clear that there are limitations. I have to admit, despite the nice correlary back to the business, I did not like this format but that is a personal issue. I'm sure others will rave about it.
Earlier on, he made a good point about how metrics should be evenly applied across multiple businesses and verticals. I think that is what he was trying to was create - a framework that would enable us to do precisely that. Unfortunately the metrics you need to create to populate the card are so unique to a given environment, that the framework provided seems like a moot point to me.
At the end of the day however, I think the true purpose was to demonstrate how one would evaluate security in an organisation, define a series of metrics and use those metrics to report on the state of security back to the organisation. In other words, how to apply the lessons in this book from start to finish. In that respect, I think he succeeded.
If I have to pick one gripe (and I admit I am nitpicking here), it would be that the Summary at the end of each chapter is largely a condensed copy of the entire chapter, often using entire slabs of text. When he covers a large chunk of material in a given chapter (e.g. Chapter 6) you feel grateful, but for others (e.g. Chapter 8) it feels redundant. I would have preferred to see less redundant language in the summaries, perhaps keeping them to bullet points if he wanted to use the same text. But again, that is just a personal preference. I expect many reader's will truly appreciate the detailed summaries.
Overall, I think this book is mandatory reading for security managers, consultants (especially those who assess and audit Technical Security Controls), security architects, and even operations folk who are looking to explain/justify their existence (or find themselves in the position where they have to continually do so) or even just gain management support to their efforts.
Too many security people say they are "too busy" to deal with report writing and measuring. I think this book creates a compelling case why we need to start thinking about security metrics more - and start today.
Rating: 9.5/10
Thursday, October 22, 2009
Mandatory Reading
Hi all
Occasionally you read a book that flips you on your head and gives you a unique spin on things. I've just found two books that fit the bill:
'Security Metrics' by Andrew Jaquith
'Beautiful Security' by Andy Oram, John Viega
I've almost finished Security Metrics and just started reading spot chapters from Beautiful Security. I fully intend on writing reviews here for both shortly but please don't wait for my review.
I strongly recommend you read these books. I am finding both fascinating reads and I can assure you that these will give you new insights and add real value to your work.
- J.
Occasionally you read a book that flips you on your head and gives you a unique spin on things. I've just found two books that fit the bill:
'Security Metrics' by Andrew Jaquith
'Beautiful Security' by Andy Oram, John Viega
I've almost finished Security Metrics and just started reading spot chapters from Beautiful Security. I fully intend on writing reviews here for both shortly but please don't wait for my review.
I strongly recommend you read these books. I am finding both fascinating reads and I can assure you that these will give you new insights and add real value to your work.
- J.
Thursday, October 1, 2009
Sources on "Best Practise" security
I had a question on 'best practise information security' today by a family member and it then occured to me that unless you're in the know, the sources for "best practise" security aren't actually listed anywhere. It's all stored on a series of disparate sources with nothing to unify them.
If information is intended to be free, why isn't this stuff more widely communicated to the non-security folk out there? Anyone would think we're trying to keep this stuff to ourselves in an effort to prop up our industry.
For example, there is no wikipedia entry on "best practise information security".
So my question is - what sources do YOU consider to be definitive when it comes to information security "best practise"?
I'll get the ball rolling with a few:
- J.
If information is intended to be free, why isn't this stuff more widely communicated to the non-security folk out there? Anyone would think we're trying to keep this stuff to ourselves in an effort to prop up our industry.
For example, there is no wikipedia entry on "best practise information security".
So my question is - what sources do YOU consider to be definitive when it comes to information security "best practise"?
I'll get the ball rolling with a few:
- NIST,
- CIS,
- NSA.gov,
- Standards (ISO/AS/NZ),
- OWASP.
- J.
Good to Great
I read a post on 'Infamous Agenda' recently and it really got me thinking... security practitioners often so caught up on putting out spotfires that we never seem to get a chance to refine our internal processes and practises.
If you're engaged on multiple projects, your requirements should be well understood, documented and easily repeatable. If there is common functionality that keeps appearing on your applications then you should have design patterns available for guidance. Classification of information assets should be defined prior the asset being built, and so on. Common sense security stuff that's a no brainer in theory but often harder to get in place in practise.
How many places can _honestly_ say that their ship runs like this - regular as clockwork?
As I am about to leave my current role and move onto greener pastures, I have spent a lot of time reflecting. I've reflected on my career highlights and contributions - my big wins. I've also spent a lot of time thinking about what I could have done differently. What mistakes did I make? How would I approach the same problem again?
They say a wise man learns from not just his mistakes but the mistakes of others. I like to think that I am my own worst critic (at least I hope so!).
Lately I've been thinking about idealism in security (as opposed to the pragmatic posts of yesterday). If we are too pragmatic we risk becoming cynical. We start to slip and lose our edge. You run the risk of not keeping focus on the items that really matter and you're no longer the gatekeeper but a rubber stamp for the business. Our idealism is what inspires us to lead and to create, it ensures we are passionate about our jobs as protectors and advisors. Lose that and what value to we add?
The difference between a good security practitioner and a great one is one that contributes some of their time each week to enhancement.
Some ideas:
It's not all about chalking up quick wins on the board like pleasing business owners, but the consistency. When you build value into the business, one day at a time, and you get to see the fruits of your labour grow over time - that's where security really demonstrates its value and that is the sense of accomplishment I have always found in my work in security.
Good security is more than just plugging holes. It's about building in the right processes into an organisation than enable them to respond to evolving security threats so that even if there are gaps that the business can respond with a degree of speed and agility. Likewise, developing a better security program means devoting time to building those processes even when you think you can't. More importantly, being a better security practitioner means devoting time to ourselves to review past failures and triumphs and learning from them (ontop of the usual insane amount of additional study we do).
In hindsight, I see a lot of things I wish I handled differently. But when I see that a single communications piece not being able to go through Marketing without a review by the Fraud teams to ensure the company message maintains a consistent approach, when Usability teams working alongside Security to ensure key functionality works as intended but doesn't pose a security risk, or even if it is something as intangible as an increased level of security awareness by multiple business units where senior management are asking security-related questions even when I'm not there, I feel like I've left my mark on an organisation and left it a little better than when I started.
- J.
If you're engaged on multiple projects, your requirements should be well understood, documented and easily repeatable. If there is common functionality that keeps appearing on your applications then you should have design patterns available for guidance. Classification of information assets should be defined prior the asset being built, and so on. Common sense security stuff that's a no brainer in theory but often harder to get in place in practise.
How many places can _honestly_ say that their ship runs like this - regular as clockwork?
As I am about to leave my current role and move onto greener pastures, I have spent a lot of time reflecting. I've reflected on my career highlights and contributions - my big wins. I've also spent a lot of time thinking about what I could have done differently. What mistakes did I make? How would I approach the same problem again?
They say a wise man learns from not just his mistakes but the mistakes of others. I like to think that I am my own worst critic (at least I hope so!).
Lately I've been thinking about idealism in security (as opposed to the pragmatic posts of yesterday). If we are too pragmatic we risk becoming cynical. We start to slip and lose our edge. You run the risk of not keeping focus on the items that really matter and you're no longer the gatekeeper but a rubber stamp for the business. Our idealism is what inspires us to lead and to create, it ensures we are passionate about our jobs as protectors and advisors. Lose that and what value to we add?
The difference between a good security practitioner and a great one is one that contributes some of their time each week to enhancement.
Some ideas:
- Creating design patterns and security architecture.
- Defining meaningful security metrics for reporting.
- Clarifying how business units formally engage Security.
- Embedding security into application development and testing processes.
- Security training for architects and developers as well as general staff.
It's not all about chalking up quick wins on the board like pleasing business owners, but the consistency. When you build value into the business, one day at a time, and you get to see the fruits of your labour grow over time - that's where security really demonstrates its value and that is the sense of accomplishment I have always found in my work in security.
Good security is more than just plugging holes. It's about building in the right processes into an organisation than enable them to respond to evolving security threats so that even if there are gaps that the business can respond with a degree of speed and agility. Likewise, developing a better security program means devoting time to building those processes even when you think you can't. More importantly, being a better security practitioner means devoting time to ourselves to review past failures and triumphs and learning from them (ontop of the usual insane amount of additional study we do).
In hindsight, I see a lot of things I wish I handled differently. But when I see that a single communications piece not being able to go through Marketing without a review by the Fraud teams to ensure the company message maintains a consistent approach, when Usability teams working alongside Security to ensure key functionality works as intended but doesn't pose a security risk, or even if it is something as intangible as an increased level of security awareness by multiple business units where senior management are asking security-related questions even when I'm not there, I feel like I've left my mark on an organisation and left it a little better than when I started.
- J.
Thursday, September 10, 2009
Cloud computing
Has anyone found any good resources on cloud computing and security?
I recently found this site:
http://cloudsecurity.org/
But I'm keen to find any other good security resources in this space. Finding stuff and over and beyond what I consider "common sense security" is actually quite hard to find.
- J.
I recently found this site:
http://cloudsecurity.org/
But I'm keen to find any other good security resources in this space. Finding stuff and over and beyond what I consider "common sense security" is actually quite hard to find.
- J.
Security Exemptions
Originally I was going to write a post on business enablement but somehow in my mind this was a nice segway into security exemptions. So I'm going to blow off my original post and instead, blather about exemptions.
I am a firm believer that IT exists to support the business and that IT should always be about finding ways for business to operate quicker, more efficiently, cost effectively, etc. To that end, security should always be an enabler. But the reality is that this isn't as easy as it sounds and this is the difference between a pragmatic and lateral thinking security advisor vs an overly restrictive one - and the reason pragmatics are more widely desired.
I suppose when firewall changes, policy exemptions, risk statements are your daily bread and butter it is a bit hard not to be perceived as the "bouncher" or "naysayer". I've had more than my fair share of this. I've also seen people who are much harder to deal with than myself. I've seen people actively try and avoid going through me because I've been perceived as difficult to deal with. I've also experienced the reverse - situations where I've been approached because I've been perceived as the "lesser" evil. I've also seen some security staff really abuse their position and block work activity for a variety of random reasons (i.e. "we weren't formally engaged!", "it isn't documented!", "not enough time to review").
It is one of the most annoying parts of being in security because it typically results in one or more of the following:
a) someone ticked off (either the security guy approving an exemption or the person whose request is rejected)
b) more work for the security advisor
c) an interruption to his daily workflow.
This is as at a minimum.
I'm not going to proclaim loudly I get these right all the time. Far from it. Infact I probably would be the first to admit I make more than my fair share of mistakes - largely from the sheer volume of requests I receive and constraints on my time that render it impossible for me to attend to these as thoroughly as I'd like. But I strive to be always conscious of my contribution when I receive these requests (see my 'checklist' below). Whats more, I've learned a lot from both my own mistakes and those of my peers on how to handle these. I also believe in the "Law of Reciprocity". Thankfully I receive so many of these types of requests in my current role that I get plenty of opportunities to practise!
And without a doubt, I would say it is the hardest part of my job.
We never win friends when we say "no" - and sometimes looking at how you can enable the business takes some very, very positive thinking. Particularly when the request seems insane and/or delusional upon first glance (I.e. "Please allow 10.0.0.0/16 through the external firewall and disable our VPN. Kthxbai"). We're often given minimal information to work with and in many cases we are given the appropriate documentation, we often have zero time to review it adequately. Then we're expected to make snap decisions on that basis.
To make matters worse, if we get any of these wrong, a litany of "bad things" can occur -
- new security "holes" are introduced that could be exploited
- risks are vastly underestimated exposing the business to higher levels of risk
- "undocumented features" appear in your network, applications and systems
- spectacular audit and compliance failures with further consequential business impacts
- hostility in the workplace
- staff actively avoiding you or approaching higher level managers to supercede you
etc.
Guess who is typically the target when any of the above occures? If you said "security" you would be spot on.
Anyway, whenever we are approached for an exemption this is my 'checklist' of things that should be going through the security advisor's mind. It is probably not complete as this is all off the top of my head, as are most of these posts:
What is the business criticality of the request? Will the business be crippled through inaction by adhering to the policy or best practise? How much pain can the business take? Sometimes it is necessary to block requests but a good advisor must really look at the request on its own merit, evaluate it against the business unit, the work involved and the company as a whole. It isn't easy to do when you're under the pump.
Has a risk assessment been performed? Can the advisor do a risk assessment - formally or informally? What is the risk appetite of the organisation? Are they willing to wear a potentially high level of risk in future vs the immediate pain of a request not going ahead? Have they signed off on the risk? Is it captured in the right register?
Are the right stakeholders across this? Are they aware of the impact - both immediate and potential? Sometimes the right people are simply not involved. Are they aware of the risk assessment? Do they agree with it? Are they willing to accept the risk? Are there other business units (Finance, Privacy, Legal) who may take a dimmer view of things than Information Security?
What is the security maturity of the business unit? Do they have a history of repeatedly trying to put security off to "another day"? Are they constantly looking for the tactical, spot solution and never the strategic response? Sometimes dragging these units through the formal process is a necessity to call them to task. Othertimes, you may need to be more agile in your thinking and look for quick wins but formalise a long term action plan, balancing strategic requirements with tactical demands.
What are the policy, legal, regulatory demands? These requirements will vary based on organisation type, industry, size, country of operation, etc. etc. Their risk appetites will vary from organisation to organisation. As such, certain requirements can be more flexible than others. Businesses vary in their regard to maintaining security. A good security advisor knows the business, knows their risk appetite, what is necessary and most importantly, knows what battles to fight.
I don't have an solutions here unfortunately. I think this battle will be going on long after I've passed from this life. But here's some strategies I've found that help:
- Focus on building solid rapport with your business stakeholders. At least then when you reject their request they don't hate you in the morning and hopefully respect remains for your position on the matter, even if they disagree.
- Look for win/win outcomes . Look for ways to say "yes" rather than "no" (I have mentioned this before). Even just thinking "how can I say yes to this request?" can have a vast impact on your approach and how solutions are found.
- Try to understand the business requirement. The whole "walk a mile in someone else's shoes" thing. Beyond understanding the simple requirement, try to understand the other person's position and what they need.
- Look for tactical as well as strategic outcomes. Security comes in all shades of grey.
- Ensure you capture the risks appropriately. Even an email articulating the risk to the right stakeholder is better than not raising a risk at all. If you can raise it in a formal risk statement and risk register, good on you.
- Don't block a request out of spite. If you block a request, be clear on your reasons why.
I'd love to hear thoughts or tales from other security professionals on their approach to exemption requests - good, bad and ugly.
Cheers
- J.
I am a firm believer that IT exists to support the business and that IT should always be about finding ways for business to operate quicker, more efficiently, cost effectively, etc. To that end, security should always be an enabler. But the reality is that this isn't as easy as it sounds and this is the difference between a pragmatic and lateral thinking security advisor vs an overly restrictive one - and the reason pragmatics are more widely desired.
I suppose when firewall changes, policy exemptions, risk statements are your daily bread and butter it is a bit hard not to be perceived as the "bouncher" or "naysayer". I've had more than my fair share of this. I've also seen people who are much harder to deal with than myself. I've seen people actively try and avoid going through me because I've been perceived as difficult to deal with. I've also experienced the reverse - situations where I've been approached because I've been perceived as the "lesser" evil. I've also seen some security staff really abuse their position and block work activity for a variety of random reasons (i.e. "we weren't formally engaged!", "it isn't documented!", "not enough time to review").
It is one of the most annoying parts of being in security because it typically results in one or more of the following:
a) someone ticked off (either the security guy approving an exemption or the person whose request is rejected)
b) more work for the security advisor
c) an interruption to his daily workflow.
This is as at a minimum.
I'm not going to proclaim loudly I get these right all the time. Far from it. Infact I probably would be the first to admit I make more than my fair share of mistakes - largely from the sheer volume of requests I receive and constraints on my time that render it impossible for me to attend to these as thoroughly as I'd like. But I strive to be always conscious of my contribution when I receive these requests (see my 'checklist' below). Whats more, I've learned a lot from both my own mistakes and those of my peers on how to handle these. I also believe in the "Law of Reciprocity". Thankfully I receive so many of these types of requests in my current role that I get plenty of opportunities to practise!
And without a doubt, I would say it is the hardest part of my job.
We never win friends when we say "no" - and sometimes looking at how you can enable the business takes some very, very positive thinking. Particularly when the request seems insane and/or delusional upon first glance (I.e. "Please allow 10.0.0.0/16 through the external firewall and disable our VPN. Kthxbai"). We're often given minimal information to work with and in many cases we are given the appropriate documentation, we often have zero time to review it adequately. Then we're expected to make snap decisions on that basis.
To make matters worse, if we get any of these wrong, a litany of "bad things" can occur -
- new security "holes" are introduced that could be exploited
- risks are vastly underestimated exposing the business to higher levels of risk
- "undocumented features" appear in your network, applications and systems
- spectacular audit and compliance failures with further consequential business impacts
- hostility in the workplace
- staff actively avoiding you or approaching higher level managers to supercede you
etc.
Guess who is typically the target when any of the above occures? If you said "security" you would be spot on.
Anyway, whenever we are approached for an exemption this is my 'checklist' of things that should be going through the security advisor's mind. It is probably not complete as this is all off the top of my head, as are most of these posts:
What is the business criticality of the request? Will the business be crippled through inaction by adhering to the policy or best practise? How much pain can the business take? Sometimes it is necessary to block requests but a good advisor must really look at the request on its own merit, evaluate it against the business unit, the work involved and the company as a whole. It isn't easy to do when you're under the pump.
Has a risk assessment been performed? Can the advisor do a risk assessment - formally or informally? What is the risk appetite of the organisation? Are they willing to wear a potentially high level of risk in future vs the immediate pain of a request not going ahead? Have they signed off on the risk? Is it captured in the right register?
Are the right stakeholders across this? Are they aware of the impact - both immediate and potential? Sometimes the right people are simply not involved. Are they aware of the risk assessment? Do they agree with it? Are they willing to accept the risk? Are there other business units (Finance, Privacy, Legal) who may take a dimmer view of things than Information Security?
What is the security maturity of the business unit? Do they have a history of repeatedly trying to put security off to "another day"? Are they constantly looking for the tactical, spot solution and never the strategic response? Sometimes dragging these units through the formal process is a necessity to call them to task. Othertimes, you may need to be more agile in your thinking and look for quick wins but formalise a long term action plan, balancing strategic requirements with tactical demands.
What are the policy, legal, regulatory demands? These requirements will vary based on organisation type, industry, size, country of operation, etc. etc. Their risk appetites will vary from organisation to organisation. As such, certain requirements can be more flexible than others. Businesses vary in their regard to maintaining security. A good security advisor knows the business, knows their risk appetite, what is necessary and most importantly, knows what battles to fight.
I don't have an solutions here unfortunately. I think this battle will be going on long after I've passed from this life. But here's some strategies I've found that help:
- Focus on building solid rapport with your business stakeholders. At least then when you reject their request they don't hate you in the morning and hopefully respect remains for your position on the matter, even if they disagree.
- Look for win/win outcomes . Look for ways to say "yes" rather than "no" (I have mentioned this before). Even just thinking "how can I say yes to this request?" can have a vast impact on your approach and how solutions are found.
- Try to understand the business requirement. The whole "walk a mile in someone else's shoes" thing. Beyond understanding the simple requirement, try to understand the other person's position and what they need.
- Look for tactical as well as strategic outcomes. Security comes in all shades of grey.
- Ensure you capture the risks appropriately. Even an email articulating the risk to the right stakeholder is better than not raising a risk at all. If you can raise it in a formal risk statement and risk register, good on you.
- Don't block a request out of spite. If you block a request, be clear on your reasons why.
I'd love to hear thoughts or tales from other security professionals on their approach to exemption requests - good, bad and ugly.
Cheers
- J.
Tuesday, July 14, 2009
Full Disclosure - Yay or nay?
I was following the recent ImageShack incident and in doing so found this article and this blog and it got me thinking - it is high time to post my $0.02 worth on disclosure of security vulnerabilities.
I don't want to delve too much into the article, but it got me thinking about my thoughts on security and why I do what I do, where do my beliefs lie, etc.
For the uninitiated, essentially there are three schools of thought -
Full Disclosure - Disclose all vulnerabilities when they are found, full details to replicate, no regard for timing, vendors to fix, etc.
Partial Disclosure - Disclosure of the vulnerabilities, with conditions. Conditions range from enough detail to find the exploit but not enough for script kiddies to copy/paste into Metasploit but enough for either a serious coder or someone with source code access to replicate. Sometimes the conditions could be around notifying the vendor, allowing some time to fix. Often termed "Responsible disclosure" (be it accurately or not).
Zero Disclosure - Vulnerabilities should never be disclosed, or at the very least, not without a fee.
There are compelling arguments for and against all schools of thought.
Full Disclosure proponents will argue that security is best promoted by being transparent about the findings and that by releasing them into the wild will force vendors to respond to the defects quickly. The idea being that vendors will release an exploit quicker than an attacker can exploit it. The arguments against full disclosure hinge predominantly that vendors have no chance to respond to the defects, and thus security globally is compromised.
Partial Disclosure suggests that disclosing the vulnerabilities is essential but there needs to be conditions attached in order to protect everyone's best interests. If a vulnerability is disclosed in full, it can be replicated by anyone. If it isn't disclosed to the vendor first, they are given no time to respond to the defect and provide a fully supported patch. Arguments against hinge predominantly on whoevers conditions attached to the vulnerability - which vary wildly to be truthfull.
Finally, there is zero disclosure. The reasons why vary from those given in the posts in the blogs above to the fact that full disclosure is little more about vulnerability researchers using public forums to trumpet their own horns and boost their own egos. Security isn't served by full disclosure as simply everyone is put at risk. The benefits of full disclosure are inherently outweighed by the overwhelming levels of risk that everyone is exposed to. Arguments against zero disclosure vary from exploits being kept secret, awaiting to be exploited by the more unscrupuluous hackers (a practise which already goes on) to promoting the ransoming of exploits to the highest bidder, leading to further exploitation and risk.
Honestly, there's more I could say on all three accounts but that's the issue in a nutshell.
So - what camp do I fall into?
Personally, I am a partial disclosure person.
Disclosure should never be (primarily) about getting the kudos. That should be an secondary benefit to promoting security. Also, I'm not saying vulnerability researchers shouldn't be paid either. I think they provide a valuable, if not essential service to the security community and the world at large. I think that mechanisms need to be put in place however to ensure that they are paid appropriately and their findings don't fall into the wrong hands.
Reading posts such as the Anti Sec blog got me thinking. It also got me mad. Not just for the fallacious logic, but for assuming that the motives of all security people is to make money and that our (ours being the security industry) efforts are to prop up undeserving corporate or government entities. Sure, there is that element and that the increasing commercialisation of the industry has attracted more than its fair share of hucksters. But I don't believe that's why we're in this.
Once upon a time, I was interested in security and held notions of some anti-authoritarian nature. Maybe I was interested because of my anti authoritarian nature. I don't remember. What I do remember is how it changed over time and my perceptions of information security became something entirely different.
These days, I like to think that securing or at least working to secure an environment is a far, far more difficult prospect than breaking into it. Far more. To the degree I think that when I read posts like Anti Sec, I can't help but wonder have they ever sat on the other side of the fence. I truly believe that if a black hat could work a week, doing what I do, they'd see there is a far greater challenge attached to working with businesses to fix their policies, procedures and practises - over and beyond the technology - to enhance security.
I understand that the proof is in the pudding - if you can still exploit software with an 0 day then all your policies, procedures, etc, can amount to nothing at the end of the day. But still, surely if our role in the world is to try and do what we can to make it a better place I cannot see how compromising systems and applications, selling off sensitive data to organised crime or supporting spammers, fraudster, child pornographers (such as Anti Sec proposed) helps to achieve that aim.
At least the traditional 'old school' hackers were in it for the exploration and learning, as much as self preservation.
- J.
I don't want to delve too much into the article, but it got me thinking about my thoughts on security and why I do what I do, where do my beliefs lie, etc.
For the uninitiated, essentially there are three schools of thought -
Full Disclosure - Disclose all vulnerabilities when they are found, full details to replicate, no regard for timing, vendors to fix, etc.
Partial Disclosure - Disclosure of the vulnerabilities, with conditions. Conditions range from enough detail to find the exploit but not enough for script kiddies to copy/paste into Metasploit but enough for either a serious coder or someone with source code access to replicate. Sometimes the conditions could be around notifying the vendor, allowing some time to fix. Often termed "Responsible disclosure" (be it accurately or not).
Zero Disclosure - Vulnerabilities should never be disclosed, or at the very least, not without a fee.
There are compelling arguments for and against all schools of thought.
Full Disclosure proponents will argue that security is best promoted by being transparent about the findings and that by releasing them into the wild will force vendors to respond to the defects quickly. The idea being that vendors will release an exploit quicker than an attacker can exploit it. The arguments against full disclosure hinge predominantly that vendors have no chance to respond to the defects, and thus security globally is compromised.
Partial Disclosure suggests that disclosing the vulnerabilities is essential but there needs to be conditions attached in order to protect everyone's best interests. If a vulnerability is disclosed in full, it can be replicated by anyone. If it isn't disclosed to the vendor first, they are given no time to respond to the defect and provide a fully supported patch. Arguments against hinge predominantly on whoevers conditions attached to the vulnerability - which vary wildly to be truthfull.
Finally, there is zero disclosure. The reasons why vary from those given in the posts in the blogs above to the fact that full disclosure is little more about vulnerability researchers using public forums to trumpet their own horns and boost their own egos. Security isn't served by full disclosure as simply everyone is put at risk. The benefits of full disclosure are inherently outweighed by the overwhelming levels of risk that everyone is exposed to. Arguments against zero disclosure vary from exploits being kept secret, awaiting to be exploited by the more unscrupuluous hackers (a practise which already goes on) to promoting the ransoming of exploits to the highest bidder, leading to further exploitation and risk.
Honestly, there's more I could say on all three accounts but that's the issue in a nutshell.
So - what camp do I fall into?
Personally, I am a partial disclosure person.
- Disclosure your vulnerabilities, give the vendor the full exploit once you've found it.
- Allow the vendor an appropriate amount of time to remediate and release a patch (bearing in mind that the gears in large enterprise environments take awhile to turn, but they do turn).
- Stay in touch with the vendor, try to keep lines of communication open to track the status of your vulnerability.
- If you don't hear from them or an appropriate time frame to the release of the patc isn't given (subjective I know - but you want to give the vendor every opportunity) , disclose it publicly but don't give all the details. Just give enough to explain the root cause and provide remediation/mitigation advice.
Disclosure should never be (primarily) about getting the kudos. That should be an secondary benefit to promoting security. Also, I'm not saying vulnerability researchers shouldn't be paid either. I think they provide a valuable, if not essential service to the security community and the world at large. I think that mechanisms need to be put in place however to ensure that they are paid appropriately and their findings don't fall into the wrong hands.
Reading posts such as the Anti Sec blog got me thinking. It also got me mad. Not just for the fallacious logic, but for assuming that the motives of all security people is to make money and that our (ours being the security industry) efforts are to prop up undeserving corporate or government entities. Sure, there is that element and that the increasing commercialisation of the industry has attracted more than its fair share of hucksters. But I don't believe that's why we're in this.
Once upon a time, I was interested in security and held notions of some anti-authoritarian nature. Maybe I was interested because of my anti authoritarian nature. I don't remember. What I do remember is how it changed over time and my perceptions of information security became something entirely different.
These days, I like to think that securing or at least working to secure an environment is a far, far more difficult prospect than breaking into it. Far more. To the degree I think that when I read posts like Anti Sec, I can't help but wonder have they ever sat on the other side of the fence. I truly believe that if a black hat could work a week, doing what I do, they'd see there is a far greater challenge attached to working with businesses to fix their policies, procedures and practises - over and beyond the technology - to enhance security.
I understand that the proof is in the pudding - if you can still exploit software with an 0 day then all your policies, procedures, etc, can amount to nothing at the end of the day. But still, surely if our role in the world is to try and do what we can to make it a better place I cannot see how compromising systems and applications, selling off sensitive data to organised crime or supporting spammers, fraudster, child pornographers (such as Anti Sec proposed) helps to achieve that aim.
At least the traditional 'old school' hackers were in it for the exploration and learning, as much as self preservation.
- J.
Thursday, July 9, 2009
Security Management
I've had a lot of time to think about what I consider to be the key success factors to good security management. I've only been doing information security for about six years - so it is not a huge length of time really. But I've worked in a lot of different environments over time and like to think I'm reasonably observant. I also pride myself on learning from the mistakes of others and not just my own.
So, with that said, I'm just going to post some of my own thoughts on this subject, but I'm very keen to hear what other people have to say. Particularly from those who have been doing this a lot longer than me.
Know Your Business
What are the key business operations, what are the key applications and environments, what are the business drivers and understanding the risks that jeopardise all of the above. What is the business strategy? What is the IT strategy? Are the two aligned and how can security help to meet these objectives?
Understanding The Organisations Risk Apetite
Who are your business stakeholders? What do they consider risky? Is it in line with the business (see above)? Do the stakeholders themselves pose a risk to the business?
Educate The Business
Make sure your business stakeholders know what the key security requirements to the organisation are, make sure they have a basic understanding of risk management and treatment options. Make sure your application support and development are aware of common security flaws and have or otherwise work towards secure application development. Ensure your infrastructure teams are aware of security best practise and all your IT teams work towards having secure standards, templates and repeatable processes to ensure security is done right - first time, every time.
Enable, Don't Restrict
Look for ways to say 'yes' to the business, rather than saying no. Find ways to encourage and support new initiatives and ideas. Find a way to implement security in such a way that you win friends, don't make enemies.
Simplify Security
Security is already perceived as restrictive and encumbent on the business, by the business. If you can find ways to build it into your processes and procedures, ensuring that security practises are automated as much as possible - then the battle is half won. Most security failures can be attributed to either human laziness or lack of awareness. Assuming your practises have been established with security in mind prior to automation, this means that the work is of a consistent (secure) standard.
Don't Stay Technology Focused
Not that the technology isn't important (obviously) but you must accept that the growing number of attack vectors and constantly evolving technology ensures it is almost impossible to stay on top of everything. Think about it - ten years ago, XSS and SQL injection were brand new. Ten years before that and web applications and VOIP were unheard of. What will the threats look like ten years from now? Can anyone of us honestly say for sure?
Having a good but broad technical skillset is more important than trying to be the best at everything. If you want to stay tech focused, nothing wrong with that - however I would then suggest you pick one, maybe two areas that you are willing to commit to. Even then, be flexible enough that you can change/adapt with the times. Certainly don't neglect your soft skills (see below).
Keep Up With Emerging Threats
This may sound contradictory to the last point but it really isn't. You don't have to understand the finer points of every new form of attack. However you must understand at a basic level how they occur, how they can be resolved and identify people with the skillsets - both in your organisation and outside of it - who can help you to plug those gaps within your business.
Soft Skills
Security is never a one man show. Even if you have no direct reports, your ability to implement security is more dependent on your ability to articulate, educate and influence than it is on raw technical skill. You can't do it all.
If you cannot specify security requirements or define the security position without upsettings your peers and stakeholders, then you are not helping security in your organisation. Learning how to deal and manage people is a vital skill if you want to do well in information security. So much so, the longer I work in this industry, the more convinced I am of this.
Know When To Be Firm
Part of being a leader is to know when to stand firm. Sometimes in security you have to take the hard line. Knowing how and when to pick your battles is crucial. Folding into unreasonable business demands or trying to constantly acquiese to the business never wins friends long term. If anything it can be detrimental to how others perceive you. Worse yet, it compromises security.
Knowing When To Delegate/ Know When To Take Ownership
Know when to delegate work but also recognise when you need to take the work on yourself. Especially the high risk items, the items of strategic importance to the organisation. Be clear on your reasons behind those decisions and stand firm on them (see above).
Have Passion
People who are empassioned are motivated. Their enthusiasm rubs off onto others. You have less uphill battles and more discussions around how to implement something rather than why.
Don't Take It To Heart
Security in the real world is an exercise in accurate risk management. The risks aren't yours - they are identified by security for the business to own. In that role, you are basically the messenger. If you haven't worked in security you may be suprised by the number of risks that are accepted on a daily basis.
Welcome to the 'real world' of information security. :)
Like picking the right battles to fight, you have to accept the ones you lost. Stay on top of your risk register as much as you can, try to make sure these risks aren't forgotten. Try not to take the risks personally (I personally struggle with this one) but just do what you can, with the resources you have and take solace in the fact that if your work has resulted in even one vulnerability being fixed, then you have made positive influence on your organisation and the world.
- J.
So, with that said, I'm just going to post some of my own thoughts on this subject, but I'm very keen to hear what other people have to say. Particularly from those who have been doing this a lot longer than me.
Know Your Business
What are the key business operations, what are the key applications and environments, what are the business drivers and understanding the risks that jeopardise all of the above. What is the business strategy? What is the IT strategy? Are the two aligned and how can security help to meet these objectives?
Understanding The Organisations Risk Apetite
Who are your business stakeholders? What do they consider risky? Is it in line with the business (see above)? Do the stakeholders themselves pose a risk to the business?
Educate The Business
Make sure your business stakeholders know what the key security requirements to the organisation are, make sure they have a basic understanding of risk management and treatment options. Make sure your application support and development are aware of common security flaws and have or otherwise work towards secure application development. Ensure your infrastructure teams are aware of security best practise and all your IT teams work towards having secure standards, templates and repeatable processes to ensure security is done right - first time, every time.
Enable, Don't Restrict
Look for ways to say 'yes' to the business, rather than saying no. Find ways to encourage and support new initiatives and ideas. Find a way to implement security in such a way that you win friends, don't make enemies.
Simplify Security
Security is already perceived as restrictive and encumbent on the business, by the business. If you can find ways to build it into your processes and procedures, ensuring that security practises are automated as much as possible - then the battle is half won. Most security failures can be attributed to either human laziness or lack of awareness. Assuming your practises have been established with security in mind prior to automation, this means that the work is of a consistent (secure) standard.
Don't Stay Technology Focused
Not that the technology isn't important (obviously) but you must accept that the growing number of attack vectors and constantly evolving technology ensures it is almost impossible to stay on top of everything. Think about it - ten years ago, XSS and SQL injection were brand new. Ten years before that and web applications and VOIP were unheard of. What will the threats look like ten years from now? Can anyone of us honestly say for sure?
Having a good but broad technical skillset is more important than trying to be the best at everything. If you want to stay tech focused, nothing wrong with that - however I would then suggest you pick one, maybe two areas that you are willing to commit to. Even then, be flexible enough that you can change/adapt with the times. Certainly don't neglect your soft skills (see below).
Keep Up With Emerging Threats
This may sound contradictory to the last point but it really isn't. You don't have to understand the finer points of every new form of attack. However you must understand at a basic level how they occur, how they can be resolved and identify people with the skillsets - both in your organisation and outside of it - who can help you to plug those gaps within your business.
Soft Skills
Security is never a one man show. Even if you have no direct reports, your ability to implement security is more dependent on your ability to articulate, educate and influence than it is on raw technical skill. You can't do it all.
If you cannot specify security requirements or define the security position without upsettings your peers and stakeholders, then you are not helping security in your organisation. Learning how to deal and manage people is a vital skill if you want to do well in information security. So much so, the longer I work in this industry, the more convinced I am of this.
Know When To Be Firm
Part of being a leader is to know when to stand firm. Sometimes in security you have to take the hard line. Knowing how and when to pick your battles is crucial. Folding into unreasonable business demands or trying to constantly acquiese to the business never wins friends long term. If anything it can be detrimental to how others perceive you. Worse yet, it compromises security.
Knowing When To Delegate/ Know When To Take Ownership
Know when to delegate work but also recognise when you need to take the work on yourself. Especially the high risk items, the items of strategic importance to the organisation. Be clear on your reasons behind those decisions and stand firm on them (see above).
Have Passion
People who are empassioned are motivated. Their enthusiasm rubs off onto others. You have less uphill battles and more discussions around how to implement something rather than why.
Don't Take It To Heart
Security in the real world is an exercise in accurate risk management. The risks aren't yours - they are identified by security for the business to own. In that role, you are basically the messenger. If you haven't worked in security you may be suprised by the number of risks that are accepted on a daily basis.
Welcome to the 'real world' of information security. :)
Like picking the right battles to fight, you have to accept the ones you lost. Stay on top of your risk register as much as you can, try to make sure these risks aren't forgotten. Try not to take the risks personally (I personally struggle with this one) but just do what you can, with the resources you have and take solace in the fact that if your work has resulted in even one vulnerability being fixed, then you have made positive influence on your organisation and the world.
- J.
Friday, June 26, 2009
Web filters to censor video games
Unbelievable. The Government keeps changing its story!.
To summarise the current sequence of events:
- The Federal Government proposes Internet filtering.
- The Federal Government does not consult relevant industry groups or subject matter experts.
- The Federal Government does not clearly define scope (and in fact changes it constantly - first child pornography, then porn, then inappropriate content, then BitTorrent/P2P, now gaming).
- All discussions of testing have collapsed, all without a tier 1 ISP (in other words, nothing close to a representative sample).
- Any exposure of the blacklist will result in fines.
Seriously this sounds like an IT project going horribly wrong. I find it amusing yet sad... I don't know if this initiative will go anywhere. Despite their intent on setting themselves up 'Big Brother', thankfully, the entire initiative sounds like it is well and truly failing. Then again, it seems the Government can argue it is a roaring success without any success criteria. :(
- J.
To summarise the current sequence of events:
- The Federal Government proposes Internet filtering.
- The Federal Government does not consult relevant industry groups or subject matter experts.
- The Federal Government does not clearly define scope (and in fact changes it constantly - first child pornography, then porn, then inappropriate content, then BitTorrent/P2P, now gaming).
- All discussions of testing have collapsed, all without a tier 1 ISP (in other words, nothing close to a representative sample).
- Any exposure of the blacklist will result in fines.
Seriously this sounds like an IT project going horribly wrong. I find it amusing yet sad... I don't know if this initiative will go anywhere. Despite their intent on setting themselves up 'Big Brother', thankfully, the entire initiative sounds like it is well and truly failing. Then again, it seems the Government can argue it is a roaring success without any success criteria. :(
- J.
Sunday, April 19, 2009
The Pirate Bay to roll out secure €5 per month VPN service
Not that I condone piracy, but it looks like the Pirate Bay are now about to launch a public VPN service for $7USD/month..
Could be useful if/when this Internet censorship thing comes to fruition. Note - I said 'if' as well as 'when'...
- J.
Could be useful if/when this Internet censorship thing comes to fruition. Note - I said 'if' as well as 'when'...
- J.
Thursday, April 16, 2009
Unruly patrons to get carded at city venues
Apologies for not posting much lately. My partner just gave birth to our first child. I'm taking some much deserved time off to be with them. :)
In other news: While this is not exactly information security I read this and immediately thought "security theatre".
- J.
In other news: While this is not exactly information security I read this and immediately thought "security theatre".
- J.
Tuesday, March 17, 2009
Banned hyperlinks could cost you $11,000 a day
Sigh and more sigh.
Seems our government isn't willing to let sleeping dogs lie, but rather, would beat the pitbull over the head with a big stick as it were.
Choice quote (from the article):
Wright was quick to pick up on the contradiction. "I don't get it either, but that doesn't stop ACMA from declaring whatever they like, or links to whatever they like as inappropriate. Today it's abortion sites. Tomorrow it's drug sites? Propaganda sites? Wikipedia?"
Indeed. :( Even during the filtering debate, it was never clearly stated whether the publishing of the blacklist or items from said blacklist was against the law (I believe they neatly side skirted that issue). To say nothing of the fact that blacklisting an anti abortion website seems to fall well into the realm of absurd.
BTW, the filtering discussion still goes on. While the debate may be shutdown in Parliament, there is an interesting article here which explores the options for the Rudd government to bypass Parliament to implement some form of filtering.
- J.
Seems our government isn't willing to let sleeping dogs lie, but rather, would beat the pitbull over the head with a big stick as it were.
Choice quote (from the article):
Wright was quick to pick up on the contradiction. "I don't get it either, but that doesn't stop ACMA from declaring whatever they like, or links to whatever they like as inappropriate. Today it's abortion sites. Tomorrow it's drug sites? Propaganda sites? Wikipedia?"
Indeed. :( Even during the filtering debate, it was never clearly stated whether the publishing of the blacklist or items from said blacklist was against the law (I believe they neatly side skirted that issue). To say nothing of the fact that blacklisting an anti abortion website seems to fall well into the realm of absurd.
BTW, the filtering discussion still goes on. While the debate may be shutdown in Parliament, there is an interesting article here which explores the options for the Rudd government to bypass Parliament to implement some form of filtering.
- J.
Wednesday, March 11, 2009
Thursday, March 5, 2009
Vendor Contracts
I gave a presentation at the Melbourne OWASP chapter recently and at this presentation, I shared some lessons learned on vendor contracts. More specifically, when dealing with vendors that are responsible for application development or delivery of a solution or product:
1. If you get engaged early enough on a project and get to review any vendor contracts that come your way, two big clauses you need to include -
Without these you have no assurance any security will be built into your solution, beyond what the vendor considers to be "secure".
2. Don't start a project without a firm contract in place. By contract I mean a legally binding agreement above and beyond a statement of work. Statements of Work are fine for short term engagements, particularly if they are followed by a consultancy agreement or similar document. They are insufficient for large scale projects.
- J.
1. If you get engaged early enough on a project and get to review any vendor contracts that come your way, two big clauses you need to include -
- adherence to your company information security policy (and other policies, statutes, etc).
- "right to audit" clause to ensure that you get to perform the appropriate penetration testing or security audit.
Without these you have no assurance any security will be built into your solution, beyond what the vendor considers to be "secure".
2. Don't start a project without a firm contract in place. By contract I mean a legally binding agreement above and beyond a statement of work. Statements of Work are fine for short term engagements, particularly if they are followed by a consultancy agreement or similar document. They are insufficient for large scale projects.
- J.
Thursday, February 26, 2009
PCI DSS - Random Musing #1
For anyone wondering why I posted random stuff about PCI when I've been harping on about Internet Filtering for months, well, I've been doing some work in this space for awhile.
For the uninitiated, PCI DSS is a standard for handling credit card security. It's been around for awhile now but its only really started gaining momentum in Australia in the past 12-24 months.
When you go to the Tier 1 merchant training sessions, talk to the QSAs, the acquirers, etc, the message is loud and clear - don't store cardholder data unless you really, really, REALLY have to. Just hand them over to the payment processor. At least that's the crux of it.
So why did I post those articles?
Well, my point is we rely on the payment processors and best practise tells you that is where the data should be going - and I agree 100%. Online businesses send their credit card data directly to the payment processors and minimise any storage of anything on their side of the fence. Pretty cut and dry right? Minimise your liability and protect your clients, reduce PCI-DSS audit scope where you can and everyone is happy - right?
Except for the consumer if their data gets stolen from your payment processor because they used your site.
You get the blame because they (the unfortunate consumer) used your site. Even though it was your payment processor's responsibility to protect that data and you did everything by the book. You get smeared by association and lose business. If you're really unfortunate and you follow this train of thought to its ultimate logical conclusion, couldn't your business go under? This scenario could easily kill a small business. If so, could the payment processor be open to a lawsuit?
PCI DSS states that any third parties you rely on for the processing of cardholder data must be validated they are PCI DSS compliant. But these articles prove that this isn't enough.
So this raises a bunch of questions that came to mind:
You be the judge.
The takeaway lesson I guess for security professionals is that we need to be asking some seriously tough questions (above and beyond PCI-DSS) when conducting vendor selection for payment processor facilities. We need to ensure they implement security to a level we think is commensurate to the level of risk. If you're in the middle of PCI DSS remediation and looking to consolidate payment processors, you're in the prime position to do so.
And somehow we are expected to be pragmatists about it. Can we make sure we aren't holding them to an impossible standard? Can the bar be set too high with cardholder data when the costs for breaches and liabilities involved are so high?
Like I said, you be the judge.
BTW, I'm not suggesting the above list of questions are perfect - or even a place to start. Those are just some random questions that just occured to me personally. I just couldn't help but wonder how serious these guys take their security and if so, to what extent do they take it and is it really enough?
- J.
For the uninitiated, PCI DSS is a standard for handling credit card security. It's been around for awhile now but its only really started gaining momentum in Australia in the past 12-24 months.
When you go to the Tier 1 merchant training sessions, talk to the QSAs, the acquirers, etc, the message is loud and clear - don't store cardholder data unless you really, really, REALLY have to. Just hand them over to the payment processor. At least that's the crux of it.
So why did I post those articles?
Well, my point is we rely on the payment processors and best practise tells you that is where the data should be going - and I agree 100%. Online businesses send their credit card data directly to the payment processors and minimise any storage of anything on their side of the fence. Pretty cut and dry right? Minimise your liability and protect your clients, reduce PCI-DSS audit scope where you can and everyone is happy - right?
Except for the consumer if their data gets stolen from your payment processor because they used your site.
You get the blame because they (the unfortunate consumer) used your site. Even though it was your payment processor's responsibility to protect that data and you did everything by the book. You get smeared by association and lose business. If you're really unfortunate and you follow this train of thought to its ultimate logical conclusion, couldn't your business go under? This scenario could easily kill a small business. If so, could the payment processor be open to a lawsuit?
PCI DSS states that any third parties you rely on for the processing of cardholder data must be validated they are PCI DSS compliant. But these articles prove that this isn't enough.
So this raises a bunch of questions that came to mind:
- Are the payment processors implementing "real" security or just trying to get ticks in the boxes of their audit?
- How many of these companies restrict outbound Internet access? Limit/filter HTTP access?
- Failing that, how many segregate their core IT systems from their internal LAN? And who has access to these systems and how is access facilitated?
- What controls are in place for their administrators and staff with privileged access? What sort of background checks are performed?
- What boundaries and checks exist to measure/reduce/prevent authorisation creep?
- Just how restrictive is the SOE? Do they have appropriate network access controls to prevent random devices (i.e. contractor laptops, executive's children, etc) being plugged into the office LAN?
You be the judge.
The takeaway lesson I guess for security professionals is that we need to be asking some seriously tough questions (above and beyond PCI-DSS) when conducting vendor selection for payment processor facilities. We need to ensure they implement security to a level we think is commensurate to the level of risk. If you're in the middle of PCI DSS remediation and looking to consolidate payment processors, you're in the prime position to do so.
And somehow we are expected to be pragmatists about it. Can we make sure we aren't holding them to an impossible standard? Can the bar be set too high with cardholder data when the costs for breaches and liabilities involved are so high?
Like I said, you be the judge.
BTW, I'm not suggesting the above list of questions are perfect - or even a place to start. Those are just some random questions that just occured to me personally. I just couldn't help but wonder how serious these guys take their security and if so, to what extent do they take it and is it really enough?
- J.
Web censorship plan heads towards a dead end
This sounds too good to be true:
"Senator Nick Xenophon previously indicated he may support a filter that blocks online gambling websites but in a phone interview today he withdrew all support, saying "the more evidence that's come out, the more questions there are on this"."
I think the writing is on the wall.
The article highlights that clearly Senator Conroy is pushing this despite overwhelming lack of public support and ignoring all facts and professional opinion and discourse. His blatant disregard for conducting fair and representative tests by failing to include any of the Tier 1 ISPS, is the icing on the cake IMHO. While it seems that sanity shall prevail, we should not let our guard down and should keep pushing an end to this ridiculuous move and see it through to the very end.
Oh, before I forget - I found this quote to be even more poignant:
""Unfortunately, such a short memory regarding the debate in 1999 about internet content has led the coalition to already offer support for greater censorship by actively considering proposals for unworkable, quick fixes that involve filtering the internet at the ISP level," Labor Senator Kate Lundy said in 2003."
We who forget the past are doomed to repeat it... indeed.
- J.
"Senator Nick Xenophon previously indicated he may support a filter that blocks online gambling websites but in a phone interview today he withdrew all support, saying "the more evidence that's come out, the more questions there are on this"."
I think the writing is on the wall.
The article highlights that clearly Senator Conroy is pushing this despite overwhelming lack of public support and ignoring all facts and professional opinion and discourse. His blatant disregard for conducting fair and representative tests by failing to include any of the Tier 1 ISPS, is the icing on the cake IMHO. While it seems that sanity shall prevail, we should not let our guard down and should keep pushing an end to this ridiculuous move and see it through to the very end.
Oh, before I forget - I found this quote to be even more poignant:
""Unfortunately, such a short memory regarding the debate in 1999 about internet content has led the coalition to already offer support for greater censorship by actively considering proposals for unworkable, quick fixes that involve filtering the internet at the ISP level," Labor Senator Kate Lundy said in 2003."
We who forget the past are doomed to repeat it... indeed.
- J.
Tuesday, February 24, 2009
PCI-DSS compliant payment card processors targeted
Two articles worth reading.
Here:
"What concerns me is that Visa and MasterCard, they clearly know who it is," Shettler said. "That just won't say anything because the processor hasn't come clean. The sort of feel it gives people is that Visa and MasterCard are covering for some unnamed organisation."
and here:
"This is clear evidence to me that the criminals know how to bypass the traditional security controls in place today," Litan said. "It's clear that they're targeting the processors now because there's much more data there. [Processors] are more centralized and the thinking is that more attention is paid to their security, but they are at the nerve center of processing systems."
I hope these guys are implementing real (paranoid level) security given they're operating in high risk environments and not paying lip service to the PCI DSS standard.
- J.
Here:
"What concerns me is that Visa and MasterCard, they clearly know who it is," Shettler said. "That just won't say anything because the processor hasn't come clean. The sort of feel it gives people is that Visa and MasterCard are covering for some unnamed organisation."
and here:
"This is clear evidence to me that the criminals know how to bypass the traditional security controls in place today," Litan said. "It's clear that they're targeting the processors now because there's much more data there. [Processors] are more centralized and the thinking is that more attention is paid to their security, but they are at the nerve center of processing systems."
I hope these guys are implementing real (paranoid level) security given they're operating in high risk environments and not paying lip service to the PCI DSS standard.
- J.
Subscribe to:
Posts (Atom)