|
|
|
Suspense building... You have to click on the link to find out what our friend Sasha Romanosky over at Carnegie Mellon, has found through anaysis of emperical data!
http://weis2008.econinfosec.org/papers/Romanosky.pdf Hint - these laws may have other benefits such as reducing a victim’s average losses and improving a firm’s security and operational practices.
The business world is getting faster and time to react is
being reduced significantly. The days where Information Security could depend
on processes that weren’t efficient or customer focused are gone, as the
business won’t wait to capture an important business opportunity.
An example of this is the expanded use of Virtual Machine
technologies such as VMWare, XEN, etc. This technology allows the business to
deploy new capabilities in a way that was unheard of 5-10 years ago. Your
partners in IT no longer have to wait for the purchase order to make it through
finance, wait for the vendor to ship
hardware or racking in the data center before deploying new IT capabilities.
Here are some ways the virtual machine example is impacting
security. Bottom line -- inefficient and
disconnected security processes are no longer adequate:
Deployment - A VM instance can now simply be deployed with
the press of a button on demand. Security Impact: Expecting to hear about new
systems through the grapevine or via an antiquated process involving paperwork
is no longer a sufficient way to maintain accurate situational awareness. You must
have integration, trust, and agile security review processes in place to
respond to the highly accelerated deployment cycles we now face.
Replication – VMs
can be replicated to many places in a short period of time using a single gold
image(s). Security Impact: If you
haven’t assessed the gold image for vulnerabilities and hardened it
appropriately, a small problem can grow into a very large one, even with a
moderate sized (100 images) deployment. It’s hard enough to try to harden
systems when one is in production, trying to change a 100 will take a
significant amount of your finite resources.
No barriers to entry
– VMs are wonderful in that you can run them on any hardware. Security Impact: This
means that your users can create a limited time VM that meets their needs and
then remove it before any of your detective controls can discover it. While
creativity is a great thing, helping users understand how to safely deploy
these is an important part of your security program.
Limited availability
- you can have the VM on demand as well as for as short a time as needed. Security
Impact: It is now economical to have an application in production for short
periods of time to meet business needs. This also means that a production
application can be put in place before you ever find out about it, putting the
organizations information at risk.
Wile this is not nearly all the risks associated with this
one technology, the above listed are examples of why Information Security must
integrate into the business. Heavy handed techniques will only alienate your
internal customers. Integration ensures
your corporate objectives of protecting information is met. If you make it hard
to do business with your customers, they will simply go around you, therefore
your processes must be efficient, easy and valuable. When you create an easy to
use process, Information Security becomes second nature to your customers. What
are your thoughts?
CFO Magazine has a great article for a
significant Information Security customer inside your organization. I suggest all security professionals read this non-technical, honest discussion on security controls and their importance.
Enjoy,
Paul
One of the other authors of Visible Ops Security recently sent the following two nuggets of wisdom while sitting in an airport that resonate with me more than ever:
"1. Sustainable information security is not possible by exectuve mandate alone. Information Security must integrate with other functional groups to mutually achieve business objectives.
2. In the same regards that only Nixon could go to China, information security must take the initiative to reach out to these groups, integrate into their daily operations and enable them to achieve their objectives while information security achieves their own."
Thanks to George Spafford for these great insights.
Visible Ops Security discusses these things in-depth, but they are important enough to draw out seperately. If we approach security as a service, with customers that need attention, we can remove the historical stereotype of the Information Security group as one who stops things on a whim and more of a business integrated function. Security can not succeed long term if it is based on a mandate, as that is only effective as long as the person mandating it is in power and only as long as security is a primary consideration. If you integrat security into business processes, you have a much longer term solution.
On another note, the three authors of Visible Ops Security were at RSA signing books. It was wonderful to meet other security practitioners (thanks to those of you who stopped by.)
The Visible Ops Security authors recently conducted a
Webinar with Info Security Magazine with the following description “How can IT security practitioners
break through organizational silos, removing the stigma associated with
security controls and compliance projects, and enabling security across the
organization?
This difficult question will be addressed by Gene Kim, George Spafford, and
Paul Love , the authors of the forthcoming book `Security Visible Ops' in
Webinar roundtable discussion and question/answer session.”
This great roundtable discussion and question/answer session covered some interesting topics. Highly recommended.
Paul
http://www.infosecurity-us.com/webinars/security_barriers.shtml
It's odd to think that as Information Security professionals, we have competition within our companies/organizations for the services we provide. One of the primary services most Information Security professionals provide is consultation on risk. In that area we have competition, but not in the manner that may initially come to mind. The choices for our internal customers for Information Security consultation include, but are not limited to:
1. Talking to other groups that may have some thoughts/input on security (such as QA, Technical Specialists, or even audit)
2. Avoiding us and using their own judgement on security risks
3. Outsourcing (such as Managed Security Service Providers, outsourcing, etc.)
Acknowledging that competition exists will sometimes help you maintain your customer focus, because you aren't the only option for your customers. If you strive to assist them and provide services to them, they will return. Of course there are instances where you must help the customer understand that a decision they are making is detrimental to security, but if you have already built up a reputation as a business focused group, your recommendations will be taken much more seriously.
What are your experiences?
I've always been dismayed when Information Security professionals are considered roadblocks. One tactic I have taken is to rarely if ever say "no" to a business project, idea or technology. My philosophy is that Information Security is a service industry, we provide a service to management to provide our expertise in understanding the consequences of their business decisions to the confidentiality, integrity and/or availability of the information we are tasked to protect. By withholding "no's" and providing alternatives instead to decisions that are detrimental to security, you end up opening the door to a longer term relationship with your internal customers, and will often be seen as a partner who is sought out by your internal customers rather than a roadblock to be navigated around.
An example of the "No" roadblock - (not recommended)
Internal Developer- This application has a cool new authentication scheme built in. The vendor indicated it is proprietary and built internally to the software and they tout that this makes it more secure.
Information Security staff - Sorry, but that is a violation of our security policy that states "Only standards based authentication mechanisms will be used." We can't allow you to move forward until you fix it. (a nicer way of just saying no, but in essence still no)
Using the method above, you just tell the developer no and lose a valuable chance to gain an ally and service the needs of the business.
A better response to same scenario (recommended)
Internal Developer - This application has a cool new authentication scheme built in. The vendor indicated it is proprietary and built internally to the software and they tout that this makes it more secure.
Information Security staff - Our policies indicate that this would be a deviation, but a way that you can still accomplish authentication, while using a central system (reducing your workload and organizational access administration activities) is to use our central LDAP system. This should achieve what you are looking for. If this won't work or limits your ability to meet your target deadlines, we can also direct you to our Information Security Policy Exception Process which allows you to approach senior management with your concerns and see if they will grant you an exception due to business need. Either way, please let us know what we can do to help.
This latter approach accomplishes the same thing as the first, although you give alternatives. Even if your alternative doesn't work, you give the developer another way to solve their problem, which is your exception process (or whatever name you have for your process of appeals.) if you don't have an appeal process, I highly recommend you develop one so that senior management (whoever owns the policies) has a way to approve deviations from their requirements when business situations warrant it.
I would like to thank all the readers of this blog. I want to make the first blog entry an explanation of what the Visible Ops Security blog will and will not be. There are a lot of Information Security blogs that talk about the technical components/controls of an Information Security program. This blog will not be one of them. In this blog, we will be discussing the other components of an Information Security program such as aligning Information Security with the business, selling your Information Security program to your customers (both internal and external), and generally the business aspects of Information Security. To start with, Information Security as with most aspects of business is about convincing others of your abilities, competence and ability to influence. If your message or plan for solving a problem is solid and the right direction for the organization, you will have a hard time getting your idea put in place unless someone else adopts it as their own who others trust. One of the first tasks you should work on when joining an organization or trying to increase your influence is to get others to trust in your capabilities. A great book (and great author on marketing) is Seth Godin ( http://sethgodin.typepad.com/ ). One of his best books on building your own brand is called "Free Prize Inside" which may seem like an odd book for an Information Security professional, but the links between marketing and starting a security program are evident as you read the book. I highly recommend Seth's blog and his books for those looking to improve their own brand (personal and Information Security program.) Please post comments and I will respond.
The IT Process Institute will soon release the second Visible Ops title. Please allow me to introduce Paul Love who is one of the authors of this new work, and a practicing Security Professional. Paul will be adding security related blogs to this forum.
Welcome Paul!
Visible Ops Security
Achieving Common Security and IT Operations Objectives
in 4 Practical Steps
In September, we’ll release the findings of our Change, Configuration, and Release performance study. One of the findings in that study, is that a focus on managing IT processes predicts performance variation accross top, medium, and low performers in the study, as much or more than change, config, and release practices recommended in industry frameworks.
One of the key predictors of performance variation across the top, medium and low performers in the organization – was how much of a process culture existed in their shop.
Some of the behavior that is common among top performers is that executive management indicates that following process is “how we do things here”, and that HR policy helps set the expectation that following defined process and procedures is a basic job requirement, and that not following documented procedures is an exception.
Bottom line – if your IT organization doesn’t follow a specific way of doing things, then IT controls and ITIL best practices aren’t going to “stick” and generate expected risk reduction or performance improvement.
One of the key findings or our most recent research study is that process maturity matters! That is, organizations with higher levels of process maturity for key IT controls got more measurable performance gain than those that implemented the same controls at a lower level of maturity. Download our most recent executive summary “Process Maturity Matters”.
This is not a surprising finding for six-sigma black belts and other IT folks who have a process improvement approach to achieving performance goals. But for others IT managers working to implement key controls to meet regulatory requirements, knowing that performance improvement comes when controls are implemented at a level where processes are consistent, exceptions are monitored, and exceptions have consequences – the findings can be the key to achieving operational gains from significant control and audit investments.
Our current Visible Ops quick poll confirms what we found in the study. That is, many organizations don’t have defined consequences for not following key IT control processes such as change management. Many that do have defined consequences don’t enforce them.
The current reality is that many organizations don’t have a process culture in IT (an early finding from our next study). So dropping controls into an environment where IT professionals are not accustomed to strictly following documented process and procedures – is bound to achieve mixed results.
Bottom line – enforcing use of documented process and procedures means that everyone needs to know what happens when they decide not to play along.
Fourth in a four part series on key metrics related to the IT Controls Performance Study.
In virtually every vocation, there are simple organizational indicators that are used to benchmark effectiveness and efficiency. A sales organization may want to benchmark itself against competitors by calculating its revenue per quota-bearing salesperson. If company management desires to increase the revenue-to-salesperson metric, they cannot achieve it by merely firing salespeople! Instead, they must do myriad things to systematically increase their sales productivity and sustain it over time. The outcome of pulling this off successfully is that the organization may very well end up hiring even more sales staff to continue their growth.
In the same way, the server/sysadmin ratio serves as an easy-to-calculate indicator of IT organization effectiveness and efficiency. It is not a management metric, but it is an interesting indicator. A far more tactical metric is percentage of time spent on unplanned work, and benchmarking suggests a linear relationship between unplanned work and the server/sysadmin ratio.
How do high performers maintain such high server/sysadmin ratios to accomplish both effectiveness and efficiency? The two controls common in high performers—they actively monitor systems for unauthorized change, and have defined consequences for intentional, unauthorized changes—result in a culture of change and culture of causality. All the hard work and process improvement initiatives pay off not only in less time spent on unplanned work and better service levels, but better efficiencies as well.
Read full article
In my previous Metrics that Matter posts, I discussed how high performing IT organizations use mean time to repair (MTTR) and first fix rate (FFR).
In this post, I'll excerpt from my recent article that covered another metric that stratified the high performers from medium and low performers that we have studied in the IT Controls Performance Study.
This key metric is change success rate. The key finding from the study is that top performers have a more stringent definition of change success rate, AND have higher metrics.
A common measure of of change success rate includes the number of changes successfully deployed without creating an incident, service impairment or disruption of work. However, top performers we studied focus on process as well as outcomes, and also include process exceptions as part of their definition of success. To them, a change doesn’t necessarily have to cause an incident to be defined as unsuccessful.
For instance, when a change does not go accordingly to plan would also count as a process exception. This could be such as when a change exceeds the scheduled implementation time or varied from the deployment plan, requiring undocumented steps. High performers would count all these examples as failed changes. (We’ve observed that high performers use the term "change process exception" to define this condition, to distinguish this from a failed change.)
For a closer look at measures and variance of top, medium, and low performers, please reference this article. Link to full article.
Here is an excerpt from an excellent recent article by George Spafford that highlights Change management's role in configuration management.
Fundamentally, what groups don’t realize is that their challenge isn’t with Configuration Management. It is with Change Management. Change Management is the process by which an organization implements the necessary procedures to control changes to production and thus manage risk. It is very important to understand that Change Management governs Configuration Management – nothing should change in production, or the CMDB, without an approved Request for Change (RFC). If production is changing and nobody knows about it then this is a Change Management failure – not a Configuration Management failure.
Link to full article.
I've recently completed interviews with 11 top performing IT shops about their change, configuration, and release practices. What struck me was how important configuration management was to these top performers.
ITIL configuration management primarily focuses on collecting and managing information about configuration components (i.e. collecting and maintaining CI data in CMDB). But the top performers I talked almost all stressed that having a standard build or golden configuration for key systems, using the approved configurations as part of a build and patch strategy, and them managing configuration drift in production - was key to improved levels of availability. The focus was not on having accurate CI data in a CDMB. The focus was on maintaining production systems in a known state to minimize risk.
So we end up with a chicken and egg question: is detecting unauthorized change, which our studies have shown is significant predictor of performance, a change control or a configuration control?
The experience of one of the companies I talked to helps illustrate what I think is the answer. They implemented a change detection system. But when the detected an unauthorized change to a production system, and they didn't know what the configuration of that system was supposed to be, they didn't know how to respond to the detected change. Point being, if you don't know what the configuration of a production system is supposed to be, then knowing that a change has occurred doesn't help identify the risk level of the change.
Overall, change detection is primarily a configuration control, not a change control. Certainly detecting unauthorized changes is an effective control for managing the change process. But the outcome that impacts service levels is that systems stay in a known configuration state.
The problem with distributed systems is that there are multiple configuration options at multiple levels of the technology stack - which creates and almost infinite set of different potential combinations of configurations and settings. If you don't identify one or two standard configurations for all Linux servers, for example, and let different developers and production admin set up different systems with different configurations, you can't possibly test and confirm the quality and risk level for each combination of technologies and settings.
Based on the experience of the top performers I have interviewed, having a strategy of identifying, testing, and maintaining a limited number of golden build or approved configurations of production systems, and actively maintaining production systems in an identified state -- is not optional for companies that are serious about uptime, data security, and proper function of critical business systems.
|