What are the strategic goals for your organization in 2012? Can you recite them off the top of your head? If you can’t, you’re not alone. The inability of enterprise security teams to answer those questions is one of the biggest obstacles facing our discipline today, and it’s the biggest reason current security metrics do not grab the attention of organization leaders.

Know Why You’re There: Business Productivity

The traditional role of security in the organization has been that of a cost-center to be minimized. Besides preventing breaches, security’s success has historically been defined by internally developed measures. We work to create best-practice metrics that show how mature the security program is, and we pass them around to one another as indications of our success. Unfortunately, those kinds of security metrics do not speak to the heart of the business.

IT has made the shift from support to delivering value. Security must follow.

In many organizations, both small and large, IT has successfully made the transition from its traditional role as a support service to driving business value. In manufacturing firms, IT has provided huge returns in implementing ERP (enterprise resource planning) and MRP (material requirements planning) systems. In marketing organizations, IT provides direct business value in improved marketing through analytics and improved CRM (customer relationship management) solutions. And in many software and solution companies, IT actually is the value the business offers, either through technical skills or solutions made by IT.

So far, security has not managed to make that same shift. We are still implementing security based on our own priorities and goals, rather than on what makes the larger organization successful. Whenever we talk about the success of our security program in terms of adherence to an industry standard, a best-practice or a framework, we’re defining our goals based on the requirements of a third party; a third party who does not have the specific interests of our organization in mind.

I am not suggesting we should abandon frameworks and build everything from scratch. In fact, I strongly believe that most security programs should be built to a framework. But it’s how we customize our specific implementation and how we view that framework that differentiates a business-enabling security program from a stifling one.

How Security Meets Those Objectives

A successful security program starts with the goals of the organization and flows from there. As an example, consider the differing needs of two organizations.

1. A small software development shop with a couple dozen employees, selling consumer software to end users.
2. A large manufacturing and retail organization that sells primarily to professionals and corporations.

Company 1 needs to create highly innovative software and get it into the hands of the consumers quickly, while trends are still hot. Company 2 needs a extensible program that can integrate with numerous vendors and partners without adding crushing overhead to the supply chain, and repeatable, provable procedures that can be demonstrated to customers and regulators. Can you imagine trying to implement the same type of security program for both of these companies? Unfortunately, that’s exactly what many security practitioners do. The key to success in both of these organizations is in understanding how the organization can be successful, and implementing security in a way that supports that success.

The objectives of the business should dictate the initiatives of the security team.

For Company 1, security must create efficient ways to rapidly enable the company to go to market, without suffering from devastating security breaches. For this security department, it may entail security initiatives like: (1) secure coding training for developers, (2) security consultation during the software architecture process, (3) automated code review as a part of the development process, and (4) vulnerability scanning and on-going penetration testing as a part of the QA cycle.

For Company 2, the organizational goals are to improve supply chain efficiencies, and reduce the overhead of achieving regulatory compliance. To provide support for these initiatives, security will (1) implement a federated sign-in solution to allow better collaboration between organizations, (2) create a tiering system for vendors, to maintain high security requirements for those vendors with access to sensitive information, but reducing the requirements on vendors without sensitive access, (3) ensure procedures and auditing exist for all processes that are required for compliance, and (4) ensure that disaster recovery plans are created and tested for all critical business functions, in compliance with applicable regulations.

Metrics That Make Sense… To The Business

After we’ve created these security initiatives that address our company’s goals, we need to measure it and show it off. Note the difference between the metrics used by Company 1 and Company 2, and how the security teams uniquely demonstrate and measure the value added to their business. First, we take the organization’s strategic goals. Under those goals, we list the security programs that we’ve implemented to support them. Next, we determine metrics that will explain how those initiatives help the business. The key here is that those metrics must be in words that make sense for the business, not for the InfoSec department.

Gone are metrics like “vulnerabilities found” and “patch level.” In their place are metrics that directly address the priorities of the business. By crafting the metrics in the language of our business leaders, we are demonstrating the value of their security investment in a way that matters to them.

Context is essential. Security measures must be written in the language of the business.

Context is key. Security exists within the context of the company that employs it. Understanding the objectives, motives and vernacular of the industry are critical. A software company may want to read about features released, time to market and improved quality. But a bank is interested in fraud cost reduction, regulatory compliance and accounts added. Knowing what makes your organization successful is essential in capturing the right metrics.

In order for security to have a seat at the table in overall business strategies, the business leaders must see that security is up to the task. They want to see that security is delivering tangible value to the overall organization. Mapping our initiatives back to strategic goals and reporting our results in the language of the business are the best ways to demonstrate that value.

You’ve heard it before, right? “Security is inversely correlated to convenience.” This is not news. It is convenient to be able to sit right down at a computer and have access to all the data. It’s not convenient to lock our car doors, shred our credit card bills, or drive at the speed limit. Yet most of us do these things (at least sometimes) because we want to keep our stereo, protect our identity and avoid dying in a traffic accident.

It’s this very nature that makes security so difficult for business people and IT folks to readily accept. Security really is hard. It is inconvenient. It takes a 10 minute process and turns it into 11, 15, 30 or 60 minutes. This is a hard fact. Why wouldn’t our business partners give pause when security comes with these kinds of burdens?

So, what can those of us in the security team do about this? First of all, we need to acknowledge it. Don’t pretend that security has no productivity cost. Explain to our business partners that yes, security does impact their productivity. Then lay out the pros and cons. A firewall will slow down the time to provision that new web service… but it will better ensure that the service can remain online (by preventing threats to its availability), the data behind it is not leaked inappropriately, and that the company can continue to function (by demonstrating security compliance to the necessary regulatory bodies).

Security negatively correlates to convenience, but remember, correlation does not imply causation

Admitting to the problem is the first step. The second is working to reduce this impact. Yes, we know that security negatively correlates to convenience. But never forget that primary rule of statistics: Correlation does not imply causation! All too often we forget that. And fortunately, there are ways to implement security that are convenient.

50 years ago seat belts were not universally allowed in cars. They were uncomfortable, restricting… let’s be honest, they were inconvenient. While the auto industry has tried to make them more convenient, it’s largely failed. (Is anyone a fan of those automatic seatbelts? I’m perpetually waiting for them to open or close.) As we kept our eyes focused on seatbelts, an interesting thing happened. Airbags emerged. Seatbelts are inconvenient. Airbags are not. Airbags allow us to increase our safety while we drive, just like seatbelts do, but they do it in a way that the user doesn’t even notice they’re there.

Information security is similar. No, we cannot eliminate the inconvenience to users, but we can find ways to maximize our security while minimizing our level of intrusion. Think about physical security. Years ago we all had a metal key to enter our offices. While not the epitome of inconvenience, fumbling for the key to get in often encouraged our employees to just leave doors propped open or unlocked. And if the key gets lost… forget about it. We had to rekey the lock and make a new key for everyone. But today almost all organizations use proximity cards to provide physical access. These cards increase security by allowing us to provide granular access to certain areas for individuals or groups, easily terminate a lost badge. But best of all, they do it while improving convenience for the end-user. It’s a lot easier to simply hold a badge near a reader than fitting the key into the lock. Easier for the end user and easier for the administrators.

Invest in areas where security can enhance the user experience

We in information security have a similar opportunity. While we cannot completely eliminate the inconvenience associated with security, we can capitalize on those areas where security can be improved while the user experience is enhanced, untouched, or minimally impacted. Before implementing a new security measure we should plot it on the User Impact chart.

Enhanced. This is the sweet spot. But, it is also the most difficult conditions to create. Web filtering is a good example of a place where we have added both security and improved the user experience. By automatically blocking the execution of malicious code, not only is the system made more secure but the end-user does not have to deal with unexpected website actions, computer slowdowns and freezes. Remember back when websites could create an endless stream of popups? Our improvements to security have eliminated that annoyance and made surfing the web more enjoyable.

Status quo. This is the situation where we can implement security that is invisible to the user, requiring no additional steps or changes to their processes. Spam email filters, and well-tuned firewalls fall into this category. If they are implemented appropriately, the user shouldn’t notice that these systems exist.

Minimal impact. This category includes technologies that do impact the user experience, but do so in the smallest way possible. Adding in-line confirmation of choices, and requiring complex passwords are security measures that require some degree of inconvenience for the user, but do so to realize large gains in security.

The goal is to drive our security solutions further up this chart. As much as we can, avoid the red, productivity hindering areas. Reducing the degree of user impact is essential to creating a security program that not only reduces risk, but does so in a way that enables the business. As we evaluate which technology to pursue and implement, there are many factors, including threat analysis, financial implications, and business strategy. User acceptance should be included in that evaluation.

Strive to maximize the number of projects that enhance or have no impact on the user, and only implement solutions that negatively impact the user when there are no other acceptable options available. As information security searches for ways to show value to the organization, the fastest and easiest way might just be to stop hindering our employees’ productivity.

Enterprise information security is a function, not a role. While we hire technical folks and call them our “security team,” the expectations around implementing security are distributed throughout the business, especially the IT staff. The security department is responsible for creating the policies and standards that govern the organization, but we depend on network administrators, system admins, developers, DBAs, projects managers, desktop support and others to ensure that those standards are implemented.

As an example, imagine…

Funding finally gets approved for those critical network security enhancements you’ve needed for years. You purchase and implement the latest and greatest firewalls, DLP, IPS, anti-DDOS and WAF systems. Things are good. Of course you realize that no security is perfect, but you feel comfortable that you’re at an acceptable level of risk.

A few months go by. Your security controls have been able to withstand the best that the bad-guys have thrown at you. Then one fateful day it happens. A harried network administrator sets up a connection from a new ISP. Within minutes of being stood up the bad guys have found recognized the new public IP and have found their way into the soft squishy center of your network.

All it took was one unapproved network change to render all your countermeasures useless. By setting up a new internet gateway without working with the security team the network admin provided the backdoor that gave malicious users no-holds-barred access directly to the corporate treasures.

The reality is that the Information Security team is only as good as the processes of the IT department they work to protect. The most basic tenet of information security governance is that when policies, standards and guidelines are created, they will be followed. Information security governance is only successful when supported by a larger, well-implemented IT governance.

I picked on a network administrator in my story, but they are just the easiest example; certainly not the only one.

• Information security can purchase and implement cutting-edge code-review tools and vulnerability testing systems, but if application developers are making changes to production on-the-fly, those tools can’t keep a web application secure.
• The security team may create standards and baselines for laptop configurations that prevent users from downloading malicious software, but if desktop support gives the user local administrator privileges, all those security tools can easily be disabled.
• The information security organization may have specific requirements for that great new system, but if the Project Management Office (PMO) doesn’t include a security representative in project scoping, the security requirements will never be known, and will not find their way into the final product.

Each member of the IT team is critical to a successful enterprise security program. Information security governance is first and foremost about governance, and that needs to be implemented at a much larger scale.

Normally we might look for signs of an organization’s cyber security fitness in metrics like patch levels, web application vulnerabilities, and firewall configurations. But in order to step back and see the real state of our companies’ information security programs, we need to include measures that capture the state of IT governance overall.

Some key questions include:

1. Are our IT teams properly staffed? Overloaded IT technicians are much more likely to skip steps. The steps they’re most likely to skip include testing and documenting, both of which are essential to security.
2. Do teams know what they’re in charge of? Every process needs one team to own it, and every team needs to know what it’s responsible for. Documentation around who owns each function is critical.
3. Do we have reliable, up-to-date inventory lists and network diagrams? We may have the best intentioned system administrators. They may be fantastic at keeping their systems up to date with all required security controls. Yet, if their documentation does not include every system for which they are responsible, we will likely have systems that are not protected.
4. How understood and accepted is the Change Advisory Board (CAB) process? What percentages of changes go through the CAB? Are we ensuring that changes to our systems are reviewed by a cross-functional team to minimize change risk? The CAB process can be a valuable opportunity for potential changes to be reviewed for their impact to the overall environment, and also can serve as a tool in keeping disparate teams informed on one another’s projects.

Enterprise Information Security is a complex subject, and it cannot be handled by the security team by itself. Maturing information security processes must occur hand-in-hand with maturing IT governance.

RSA Conference is the big event of the year for enterprise security. All the biggest names of the security world come out to sell their books, lead a session or keynote, and sit on a panel (or 5). Everyone who sells a security product or service sets up a booth in the expo hall, or at least walks around meeting with clients and other vendors.

Long-time RSA attendees gripe about how folks leading the sessions are not presenting anything innovative or new. Dozens of vendors throw parties and receptions filled with free booze and food to connect with current and potential clients. Vendors give away hundreds of the latest hot technology (iPads and Kindle Fires!) and thousands of branded t-shirts. There are hundreds of security-centric sessions ranging from how to securely code an application, to legal aspects of security, to how to give a presentation to the board of directors, to a couple sessions this year titled, “Grilling Cloudicorns” and “Earth vs the Giant Spider.” (Side note: My personal favorite session of the week was actually at Security B-sides. It was about how differently the movie Star Wars would have turned out if Darth Vader [the CSO for the Empire] had implemented a better security program.)

Unlike Blackhat or Defcon, the value of RSAC is not releasing new hacks

In the midst all of this noise, the astute observer can pick up interesting trends. RSA Conference does not make the news like Defcon or Blackhat with all the newly released hacks. RSA reports the news. RSA tells us what corporate security leaders are working on, what topics are most important to them and where they are spending their time and money.

The news from RSA 2012 as I see it…

1. We’re getting tired of talking about the Cloud, but we haven’t even begun to finish the conversation. The general tone I heard is that we’re tired of the Cloud as a buzz-word. We’re tired of having to discuss the same Cloud-y topics over and over. But the fact is, we need to keep doing it. The Cloud sessions were well-attended because for many security leaders, it’s where our organizations are going, and we’re not prepared to lead the way yet. So this love/hate relationship with Cloud security exists. We know we need to keep learning and pressing more into all the details of moving our services to the cloud, but we all hate to be trendy.
2. BYOD is the phrase of the year. Some people call it “consumerization” of IT… but that’s so 2010. Bring your own device (BYOD) was 2012’s hottest topic, with long lines to get into those sessions, especially anything that dealt with the iPad or iPhone. This subject most reveals the lagging nature of security. The first iPhone was released in 2007, and the first CEO probably required his IT staff to support it about 15 minutes later. Yet we are still working on the right balance of corporate governance versus consumer freedom, and how we can enable remote access to corporate data without running the risk of this data getting into the wrong hands. The significant interest in this topic at RSA this year tells me that BYOD has reached the tipping point, and in a couple of years it will be expected in the same way VPN is assumed in all organizations today.
3. Big data. Personally, I think this topic is cool, and this is probably my favorite trend from RSA. Analyzing big data is a relatively unexplored frontier. We’re doing an adequate job of aggregating logs and amassing large databases. But we’re terrible at figuring out how to parse this data and deliver real value to the business. This is a problem for all of us… the business, IT and InfoSec. There were a number of sessions where we could talk and learn more about how security can utilize big data to discover trends and better protect the environment. But there’s so much more to learn, we haven’t even scratched the surface.

Cloud… BYOD… Big Data. I used all the big buzz-words didn’t I?

A mathematician wakes up smelling smoke coming from the neighbor’s house? He runs outside and sees the house ablaze. Thinking quickly, he sees a fire hydrant and a hose sitting nearby. “A ha! A solution exists!” Having solved the problem, he walks back home to get some sleep.

I believe that the interactions at the RSA Conference are an important step on the path to putting out the metaphorical fire. The information security community has a great supply of both mathematicians and firemen. No, not everyone at RSA is creating unique solutions, but they do spend time at the conference exchanging war-stories, providing tips regarding what has been successful, and getting revved up for another year’s worth of fire-fighting. By getting involved in conversations with those who have been on the front-line, we can learn from each other’s experiences and improve the entire community’s ability to execute our strategies.

RSA 2012 is in the books. The crypto-geniuses have gone home and are again working on solving our most challenging technical problems. The rest of us have returned home with some new insights and an improved plan for implementing security in our own little corners of the world. RSA offers a unique value to each of us. I hope to see you there next year.

I attended the professional development track, and pulled most of these quotes from there. Follow me on twitter to see what strikes my fancy in real-time.

• Remember that being a security leader is first and foremost about leading. Too often we get bogged down in management. Managers deal with complexity, scheduling and resource allocation. Leaders deal with setting a direction and figuring out how to get there. The quote which was used in this session, which I love, was “managers follow a map, leaders follow a compass.”
• The biggest key to the success of any security program is achieving goal congruence with the greater organization. Every security objective should directly support the overall objectives of the company. We in security must figure out how our projects contribute to the organization’s success.
• One of the comments that stuck out to me was drawing the difference between CIO’s and CISO’s. Per this presenter, CIO’s want to be remembered often. CISO’s want to be remembered not at all. While I understand and appreciate the concept (much like a baseball umpire never wants to be talked about after the game), I believe it’s an outdated model for a CISO. Today’s security departments need to find ways to add value to the organization, stepping out from behind the curtain. Instead of focusing solely on avoiding breaches, security can add value to organizations in the sales process, by providing product innovations, and assisting in the achievement of company objectives. I believe that the most successful CISO’s in coming years will be front-and-center in senior leadership strategy sessions.
• Understanding security is not enough. To create an effective security program, first we must understand the business we’re supporting. In the vein of the Prayer of Saint Francis, “not so much seek… to be understood, as to understand.” We must first look to understand how the business can be successful before we can be successful in security.
• “The destination should achieve compliance, not be compliance.” This is what I’ve been saying since I started this blog, and believe is more true now than ever. It seems like we all agree… but we must go from agreeing about it to practicing it. That’s the challenge, and it requires real proactive work, getting ahead of our requirements, rather than continually trying to catch up to the latest audit report, or regulatory update.
• Let’s ban the phrase “best practice.” It’s much like the one-size-fits-all shirt. It doesn’t really fit any of us. The thin folks are swimming in it and we bigger folks look like a sausage. No two organizations will need exactly the same security program. A security program must be much more like a custom-tailed shirt, hiding our trouble-spots, and accentuating our strengths.

It seems you can’t make it through any IT related article or meeting these days without a discussion of “the cloud.” Every CEO wants to know how the cloud can improve innovation and productivity, and every CFO wants to know when we’re going to move to the cloud to dramatically cut the costs of doing business. Most CISOs are just scared to think about all that data sitting outside our firewalls.

In the security arena our job is to help identify and quantify the risks associated with such a move. The risks of an internally hosted application are well-understood, and more organizations have an established procedure to handle them. Information security controls such as firewalls, intrusion prevention systems (IPS), data loss protection (DLP), anti-virus, and vulnerability management programs are implemented to protect the organization and keep risk exposure at a certain level. A centralized authentication system (such as LDAP or Active Directory) is used to ensure users have access only to those systems to which they are authorized.

In an outsourced environment, the corporation loses control over the implementation of security controls. The outsourced vendor provides the security controls they deem appropriate, according to their own risk tolerance. Depending on the industry, this may or may not meet the needs of your organization.

Information security must not be the roadblock that prevents cloud adoption

While the scope of the security implications change based on the particular project, below is a list of questions to help you start evaluating the risk involved with moving your data outside the organization’s boundaries.

What kind of data will your vendor be hosting?

Look very closely at any associated regulation. HIPAA, PCI, GBLA and safe harbor can all be concerns for the data your vendor will store. Ensure not only that the vendor’s security is adequate, but that they can prove it for your regulators.

Who will have access to the data at the vendor’s facility? Are they renting space from a data center company?

If so that organization’s employees may have access to your data as well, requiring yet another level of due diligence.

How are your employees going to connect to the outsourced system?

Leased line VPN? VPN over the internet? Will the system be sitting on the public net? Each of these connection strategies has their own risks.

If a leased line is used for VPN connectivity care must be taken to understand the reliance on the ISP to provide access. If the circuit fails, access to the outsourced system will be unavailable and at the mercy of the ISP’s service department.

If a site-to-site VPN is utilized, care will need to be taken to ensure that the scope of access granted to the vendor it understood and accepted. Opening a VPN tunnel allows for the possibility of data and malware moving between the organizations. Restrict the access to the smallest scope possible.

Is the system created with appropriate application security in place? Are proper steps taken to reduce risk of issues like cross-site scripting, SQL injection, and cross-site forgery attempts?

These issues are especially critical if the application will be available over the internet. Factor in the cost of running (or contracting with a third party to run) penetration tests against the vendor’s environment if necessary.

How are user accounts created and disabled?

If the organization’s central authentication system is not used, how can you ensure that users are not able to access the data once they have been terminated? Many outsourced systems will contain data that would be damaging in the hands of a recently terminated employee.

The cloud offers tangible boosts to productivity, flexibility, and scalability and does so while providing the means to reduce IT spend. Information security must not be the roadblock that prevents the adoption of such technology. By thinking ahead about the kinds of risks that outsourcing our systems will involve, we can be ready to quickly and securely lead our organization into the cloud.

A penetration test is a method of evaluating the security of computer systems or networks using manual or automated tools. Basically, we set some experienced folks out with the instruction to figure out a way to break the security of our own systems. This will usually come with some rules of engagement (no testing during business hours, don’t corrupt any of our production data, etc).

I’ve been a part of numerous penetration tests. It seems that every organization has them these days. For the purposes of this article, I am limiting us to internal penetration testing, not tests performed by customers or other third parties.

The reception testing receives varies wildly from department to department or person to person. Joe the network admin is eager to get the results of the test and see how his security measures hold up against an experienced penetration tester. However, Jan the server admin hears that a test is coming and starts shutting down services she knows are vulnerable. In reality, I see a lot more Jan’s than Joe’s. As a general rule, the response to a penetration test is a barely-covered groan, and gritted teeth.

So, why is there such a negative response to our penetration testing efforts? The primary issue isn’t that these technical folks want to hide from the truth. These are well-intentioned, competent professionals who truly want to create world-class information systems. Their reluctance to undergo a penetration test is directly related to how the results are relayed to them.

Oftentimes penetration testing becomes a ‘gotcha’ game:

• “You told us that there were no systems running telnet… GOTCHA.”
• “All your email servers are supposed to use TLS… GOTCHA.”
• “I found a Windows box still vulnerable to this old vulnerability… GOTCHA.”

When we get deep into the weeds of any penetration test, the results are not going to be pretty. Some systems don’t get patched like they should. Some servers get stood up outside the proper change controls. These types of exceptions cause penetration test findings and look bad. They are gotchas.

But is that why we’re performing penetration testing? Yes, there is value in documenting the exceptions so they can be fixed. But my take on penetration testing is that our goal is less about finding those specific failures than it is about tracking our technical risk trend. Are we becoming more secure or less? If we have more unpatched systems, this shows us that our enterprise patching process needs some tweaking (or maybe complete reworking).

Penetration testing is simply one way to measure progress over time

Before we can change the way our IT departments will react to our penetration testing, we must change the way we view, conduct and report them. No penetration test is ever going to come back clean. As the security department delivering the results, it’s important that we set the proper expectations. We are not performing this test to give a long list of To Do’s. We’re providing this as a snapshot of how risk mitigation is going, and where we should apply more emphasis going forward.

What do we do with the results of the test? If we’re simply handing them to IT and walking away, we’re missing a critical opportunity. When we deliver these results, we should schedule time to meet with the stakeholders, discuss the findings, and give meaningful, actionable steps for remediation. Just providing the findings will be seen as handing off the issue. We can become partners by working toward a solution that will satisfy both the security, resource and business requirements.

Remember, the goal of security is progress. Penetration testing is simply one way to measure progress over time. We support the business by showing them how they can improve within their constraints. Penetration testing may never be the most popular activity for IT, but if we stop saying, ‘gotcha’ and start providing meaningful solutions to real problems, it can be a more welcome event.

I can’t believe it’s already been a year since I wrote my last Resolutions post. Overall, I believe those resolutions hold up pretty well. I’ve taken a few minutes to think back over 2011 and see how I did at achieving my resolutions… I am reminded that this ride isn’t a simple pass/fail endeavor. With that in mind, here are my 2012 Enterprise Information Security Resolutions.

1. Successful information security is about making progress. It’s not reasonable or sustainable to expect all risks to be remediated as soon as they are discovered. Instead, my goal for 2012 will be to establish a positive trend, working toward improving security consistently and manageably.
2. Become an expert in the business. Yes, being the expert in information security is critical to my success, but formulating effective security strategies requires more than just knowing security, it requires knowing how my company works, inside and out. What will be the effects of making that security change? Which business functions are most critical to the company’s success?
3. Don’t trust technologies to fix security problems. All too often we are presented with technologies that can ‘fix’ our security issues. While we absolutely must have those innovative technologies, they are seldom going to be the fix root issue, and they will NEVER fix it without the proper support, analysis and scoping to make the technology work.
4. Be a positive change agent in my organization. Security can often be seen as a road-block or impediment to progress. I must go into every project meeting, and hear every new technology request, not with a mind toward how hard it will be to secure, but toward how I can insert security into the process to make it better and safer for the business. My immediate response will be ‘how can I accommodate that?’
5. Learn from cross-functional experts. Security doesn’t really exist as its own discipline. Information security is really a subset of application security, network security, email security, and many others. This resolution is more about a mind-set than anything else. I want to ensure that I view security as a part of a bigger picture within each of these disciplines and leverage those functional experts to understand context.

2012 is going to be a great year.

-Robb

What does a successful information security program look like in an organization? The traditional answer would be something like, “Technology risks are kept to a level the organization is willing to accept.” That sounds pretty simple right? Find the places where risks are greater than we’re comfortable with, then fix it.

That type of thinking works for a point-in-time evaluation, but comes up lacking when we consider the dynamic nature of enterprise information security. Things change. New vulnerabilities are discovered, new types of technologies are implemented, and new business requirements arise. In reality, there is never a point in time at which we have adequately addressed all of our technological risks. The rate of exploit discovery and the lifecycle for fixing vulnerabilities ensures that we will always have open issues.

With that reality in mind, we need to reconsider what makes a successful security program. Security should focus not on an end goal of “good enough” but on an end goal of sustained improvement.

Security can often come across as a demanding, RIGHT NOW discipline. And there are some good reasons for it. We know that hackers could break into the network right this moment, and that gives us real urgency.  The newest hacks from researchers show that even most trusted systems are vulnerable to exploit. The reasonable first response to this is to jump into action and immediately fix the issue.

But when we work with the business, the reality is much bigger than just security. Our partners in the business have to worry about losing customers because they don’t delivery our products on time, competitors out-innovating us, risks of financing falling apart, and many other business issues that could damage the business just as much (or more in many cases) as a security incident could. In the background of all these competing interests, a security manager who continues to insist that our vulnerabilities are the number 1 priority is going to get tuned out, or worse.

As soon as we stop enabling the business to produce better and faster, we become a liability.

What we can do instead is collaborate with the business to come up with a long-term plan for implementing security that does not inhibit innovation and progress by the business, and shows sensitivity to the overwhelming demands that they are often under. Yes, the plan we agree on must take the organization to a level of acceptable risk. But we can do so over months and years instead of days and weeks, show improved security over time, and develop trusted partners within the business.

Enterprise security is a service function. We exist to enable the business to do their jobs without being crippled by cyber-attacks and unreliable systems or losing their trade-secrets to competitors. As soon as we stop enabling the business to produce better and faster, we become a liability.

“You don’t have to floss all your teeth, just the ones you want to keep.”

I remember, as a child, going to the dentist and seeing that slogan on a poster on the wall. Between that and the serious questions about my brushing and flossing habits during the appointment, it would have been impossible to walk out of the dentist’s office without a full understanding of the importance of consistent oral hygiene. I would leave the dentist’s office (greatly relieved to be free) but without any commitment to adding flossing to my plans. I just didn’t want to do it, no matter how many posters suggested I needed to.

As an adult, I try to make it to the doctor every year or so. The doctor will ask about my exercise habits (not enough), and my diet (not the best choices) and then go on to explain to me the importance of improving those habits. Then we do some blood work and call it a year. I’ve been fortunate enough that my tests have always been normal, and no cause for alarm. So I would figure, “The test results are okay, the diet and exercise must not be all that important for me. I’m good for another year.”

As much as I trust my dentists and my doctors, I take what they have to say with a grain of salt. It’s their JOB to tell me to focus more on their stuff. Of course they are going to give me a little lecture, it’s pretty much expected. And if my teeth were ever to fall out, or I was to ever develop a medical condition because I hadn’t followed their directions, I certainly wouldn’t blame them. It would be nobody’s fault but my own.

Does this sound familiar to anyone? Aren’t we, in information security, playing exactly the same role in our organizations that our doctor’s play in our healthcare? We in information security evaluate, diagnose, and treat our patients, just like our doctors do for us.

Our evaluations are often called risk assessments instead of checkups. And just like patients at the doctor’s office, our customers will skirt the truth, try to reduce the scope, and may outright lie to us to make themselves seem healthy. The perception persists that security exists to punish or inhibit rather than to help the enterprise better achieve its goals.

Just like the doctor’s recommendations, our patients are only going to follow our advice when it’s easy for them

Our treatments involve implementing controls to bring down the risk. Instead of prescribing a better diet, more exercise or the newest drug, we prescribe documented processes, improved configurations, additional training or technical systems. And just like the doctor’s recommendations, our patients are only going to follow our advice when it’s easy for them. Many doctors default to prescribing a drug because they know it’s the only thing most of their patients will comply with. In the same way, in information security we can get a business unit to implement a new IPS or DLP, but trying to get them to make a ‘lifestyle change’ (more secure processes, implementing security earlier in the SDLC, ongoing security training) it too much change to be easily accepted.

In the end, security only provides value when feedback is heard, accepted and integrated. We cannot force the business to eat their carrots and do their pushups, but it’s our job to keep reminding them.

See previous posts for more thoughts about getting the organization to buy in to the mission of security.

Tip of the cap to HackerOutfit for starting this conversation.