The “three-legs” of support for information security

In the Information Technology (IT) world, technology is king.  But in information security (IS), technology is just one support of the overall IS function.  Since information security involves giving direction to people’s activities interacting with sensitive information, a balance must be achieved between the “three-legs” of information security management; people, processes and technology.  Let’s break these down individually.

People

Security begins with each individual, whether authorized, or unauthorized, accessing and protecting information. In many of these interactions, technology isn’t even involved (i.e. speaking to another individual, talking on the phone, physically handling paper records, etc.).  So the first leg of protection has to be “People”.

In order to start working with people you have to start with trust.  If you can’t trust your workers to only access that information they’re authorized to see, or you can’t trust them not to disclose sensitive information they know, then the battle is already lost.  Yes you can take disciplinary actions against an employee for a violation of a corporate policy, or criminal action in the case of fraudulent activity, but this is “closing the barn door after the horse gets out”. When it comes to interacting with people, proactive security activities are the better road to take.

Do periodic background checks – Doing a background check on people who handle sensitive information when they join the company is always a good idea, but don’t stop there, do periodic checks.  People’s lives change, and unfortunately not always for the better.  That trusted administrator who joined the company a decade ago may now be financially influenced to sell sensitive company information due to a long-term illness or layoff in the family.

Know who handles sensitive information – Seems a no-brainer that you’d know who has access to sensitive information.  The reality is, in today’s complex organizational structure, without a close examination, you may not discover who has this access.  Information, depending on the associated data a worker has access to may become sensitive without management’s knowledge.  The Navy did a study during World War II where a series of sailors calling home each had a small piece of information about their deployment.  When the war office put all this data together they learned where the ship was going, how long is was going to be there, its basic mission goals and other critical information that would have aided any enemies who were listening.  The Navy started the campaign of, “Loose lips sink ships” understanding that even the lowest ranks had information that could be detrimental if exposed.

Do security training for all people handling sensitive information – Making people aware of the policies and procedures around protection and proper access goes a long way towards achieving a good information security program.  The employee learns what is expected of them and the corporation gets a good security citizen that can also augment the company’s security personnel by keeping their eyes and ears open in reporting unacceptable behavior.

Create a communication channel of trust – Get affected workers involved in new security programs.  Allow business managers to voice their requirements.  Involve key stakeholders in security decisions.  As humans we have some of the most sophisticated communications capabilities among all the species on Earth, use them.  Throwing information security initiatives over the wall to managers and employees is unacceptable in today’s business environment.

Policies & Processes

OK, you have the eyes of the people upon you, so what’s next?  You have to provide guidance on what actions are acceptable and not acceptable to the organization.  It’s one thing to tell people they have to protect information, but you have to provide instructions on how the company wishes this to happen.

Develop policies and processes that make sense – I periodically review policies and processes for my clients.  There’s nothing worse than to find a series of policies and processes that don’t reflect the culture or organization of the enterprise.  Asking for people to stop their actions while they wait for someone to authorize an action that isn’t in their chain of command, doesn’t have this decision as a priority, or is difficult to contact will cause the process to fail.  When you create policies and processes they must reflect the real-world your organization operates under.

Create an “enforceable” set of policies and processes – I once worked with a company that had a policy that stated, “All sensitive information must be encrypted at rest.”  So I asked if this meant that every database and LDAP directory they had all ran encryption software.  Of course the answer was no, it was a best-practice policy developed by an outside consultant for the company.  So my question is “Why take the time and effort to write a policy or process if it isn’t enforceable?”  Either people won’t abide by it, or worse, they will create their own alternative processes that make their job actions easier, not necessarily making the company more secure.

Make the policies and processes easily accessible – Keeping these documents (electronic or paper) under lock and key doesn’t help anyone.  Distribute these freely to the management and workforce.  In addition, always note at the top of each document who the responsible person is for maintaining this document along with contact information.  People may need to review a particular policy or procedure in a time of crisis and having to take the time to hunt down the document may be the difference between a successful or unsuccessful detrimental activity to the company.

Update them on a periodic basis – Conditions change, opportunities come and go, legislative and corporate compliance efforts may grow, as such, a good company periodically reviews ALL their policies and procedures, but not all at once.  Create a review schedule that reflects the rate of change and resource availability of the company.  A company I worked with has about twenty-five corporate policies.  Of these, five are reviewed in detail each year meaning that every five years the entire set of policies get a makeover in a round-robin process.  Of course if you decide to do this, the information security office should work with executives to determine what the review cycle should be for their organization.

Ok, now that we’ve got the eyes of the people, we’ve given them direction and they’re protecting your information, now what?  You need to select tools to improve the efficiency and scope of this protection.

Technology

Technologies are not an end in information security; they’re a component of information security.  They should be selected to work with your people, policies & processes. 

Technology should be used to streamline and augment protection mechanisms – An administrator cannot physically review and approve thousands of e-mails that come into and out of a company.  But technological tools can do this very easily.  In those cases where an information security function is financially not viable, is too complex to implement in process, or too resource constrained to maintain a good security activity you should consider a technology solution.

Technology may require policy and process changes – The technologies you choose could influence how people securely access sensitive information.  As technological changes occur, training and policy & process changes may be needed.

Technologies are only as good as their configuration – I read vendor promises of 100% compliance, elimination of fraudulent activities, etc.  Well in theory maybe, in reality, not without a lot of work.  These tools have not been developed solely for the use of your company.  They need to be configured, or mapped, to your unique requirements.  Best practices and default settings rarely provide the optimal protection of information.  Don’t deploy any solutions until you’re satisfied they work as well, or better, than how you protect your information today.

Remember, technologies don’t get the blame when things go bad, you do – Treat technologies as tools.  Just like a bad carpenter, a hammer in his hand may not product the results you expected.  Relying on technologies to do your job is a fatal mistake; they can only go so far in providing information protection.  You are ultimately responsible to ensure the protection of your company’s information.

In the end, people, policies & procedures and technologies need to work in conjunction with each other. One of the main activities of a security manager is to keep these three in proper balance.  Only when they equally work together can you feel comfortable that your information security activities will support the needs of your company.

r

Selling IT services to business managers

As I talk to various organizations one question always comes up, “How do we sell this thing to our management?”  I’ll go into my thoughts on what you need to consider but before I do I want to relate a story that happened to me that changed my whole outlook on selling IT services to business people….

Early in my career I was working on a project with a client to architect an identity management solution.  Upon completion of what was a very wonderful experience, our proposal for funding and resources was sent to a VP of the organization for approval and submission into the budgeting cycle.  We’d ensured we dotted every “i”, crossed every “t”, had strong data around costs and deployment, and just knew this was a certainty for approval. 

Just before we expected the project to be approved, the VP asked to have the project managers come to his office.  We figured there might be some discussions about the numbers because of their size so we were prepped with our justifications, our analysis and our estimates when we walked into his office.  He had us sit down at his desk and he said, “I’ve read over your proposal and I’m getting ready to approve it if you can answer just one question.”  Thinking we had prepared for any questions he might have, we were ready to jump on whatever he asked.  He looked up and asked a simple question which we hadn’t prepared for and that left us speechless, “I see you’re proposing a technical solution worth a substantial amount of money.  The only question I have is how will this help me build our {widgets} better and/or cheaper?”  We had prepared to talk about how this project would improve processes, reduce risk, eliminate redundancy but had lost sight of the fact that the business didn’t care about infrastructure “stuff”, they wanted to be the best in producing their product at the greatest efficiency. 

Ever since that experience I’ve tried to focus on “business benefits” and not “infrastructure benefits”, a lesson I’ve shared with many people I’ve worked with and who have been better justifying their projects after my telling this story and working with them a bit.

Ok, so you probably aren’t concerned about what I learned and are waiting for me to talk about the topic at hand….

The first and foremost thing to understand is business speaks a different language.  Think about if you had a detailed message to give to someone and you spoke English and they spoke French.  The letters look similar and there may be some words that could be understood by both but the overall message is lost in the translation.  While IT project managers talk about improved user experience, reduction in duplication of IT services, policy enforcement, identity lifecycle management, modular infrastructures, etc., mid- to upper-managers talk about business need, operational efficiency, cost containment, risk management, regulatory compliance, competitive advantage, etc.  The words look similar and may be somewhat understood by both but they’re two different languages.

I instruct many project managers that if they’re not aware of their executive management’s year-end goals then they had better get a copy of their company’s annual report or talk to someone as high up as possible.  It may be easy to explain the benefits of a multi-million dollar provisioning system to IT project managers but explaining how this expensive piece of technology maps to the business managers’ overall goals for the company may be extremely difficult, if not impossible without some “language translation help”.

The next thing you have to remember is getting the stakeholders involved up front means you have an ally in the end.  Too many times, the project team responsible for scoping a new service or technology only talks to other technical personnel and don’t get line of business (LOB) managers or end users involved with the process.  “Throwing services over the wall” that benefit IT but not the business won’t sell very well outside the IT department. Stakeholders should participate in the business problem identification, requirements interviews, be kept informed on the progress being made during the analysis phase, and briefed on your services choice(s) before the final decision is made.  In all phases of the project you’re looking for “consensus”.  Not “approval” but not “against” either.  Remember if they’re not against you, they must be for you.  And the side benefit of getting the stakeholders involved is they’ll evangelize and socialize your project for you, a built in marketing team.

Mentioning services (not solutions), you have to sell services based on business functionality, not technology; drop the TLAs (three letter acronyms).  Selling an LDAP directory as an LDAP directory or a Data Loss Prevention tool as a DLP tool, will daze and confuse non-technical managers and end users.  When you sell a solution the sales pitch shouldn’t be, “We have a new directory service that supports LDAP, has 26 APIs, runs on UNIX and can be interfaced to your end system using your vendor’s native admin interface toolkit.”  A lot better sales pitch would go something like, “We have a service that will allow you to incorporate the data you need in your manufacturing process using a corporate-supported solution with little to no development costs to you allowing you to no longer need to manually input this data thus reducing any errors or missing data in your manufacturing process.”  If you were the manager of this group, which pitch would you want to hear?  The first uses a bunch of technical jargon where the second has; who has the cost of ownership (not the LOB manager), why the LOB manager needs it, what it will cost the LOB manager (little to no cost), and the benefit (reducing errors and having more complete information).  A LOB manager, and their boss, and their boss’ boss will understand these terms. LDAP: good luck.

If there is a high cost for the solution, prepare lower cost and other alternative recommendations.  Fixing a deficiency or adding a new service isn’t a bipolar decision.  There are generally several alternatives, not all involving technology that may be beneficial to the organization.  Exploring and documenting the alternatives are a way of ensuring something gets done even if the optimal solution is rejected.  After getting a “Dear John” e-mail from a manager rejecting a technology proposal, I’ve interviewed them to understand why the project was rejected.  Of course “cost” is the most common reason, followed closely by “the funds have been reallocated”, but pulling out one of the alternatives the project team had considered that met 80-50% of the stated goals at substantially reduced cost has sometimes gone through (many times management sincerely wants a solution to the problem the project team has addressed else they wouldn’t have allowed all the time and expense for the team to work on it).   

I could probably write a book on this topic but I’ve tried to highlight some of the top considerations in selling IT projects to management.  If you’d like to hear more on this topic, just leave a comment.  I’m willing to help you sell these things!

r

Putting your eggs in one basket – finding the “suite” spot

Ok, so you’ve got a product, or a few products, from a Security or Identity Management vendor and either their Sales person has told you about their new “suite” of products or you have a new business requirement for a functionality that makes buying the vendor’s suite attractive.  I’ve seen this scenario play out a thousand times.  The problem, does it make sense to put all your eggs in one vendor’s basket or do you look around for individual best-in-class products that meet your new requirements?  A lot of times organizations take the easy way and lean towards the vendor already in place – they have a relationship with the vendor, or it’s easier to get funding because they’re on the “approved vendor” list; or it would just take too long to do a good analysis of the competing products.  But baring these factors, how does an organization decide?  Well, here are some of the areas I look at:

Composition of the suite: Vendors generally develop the products that make up their suite in four ways. They have an internal development team that produces them.  They purchase a company that has solution(s) that complement their existing products and integrate them.  They resell another company’s solution(s) because the value of purchasing the other company is too low, or they’re too big.  Or they get their marketing team together and create an umbrella brand for all their products whether they’re integrated or not (i.e. whiz-bang-security, whiz-bang-monitoring, whiz-bang-identity, etc.). 

In order to understand how the products in the suite work together you have to ask your vendor a series of questions.

• How mature is the product you’re looking at?  Is it at V1.0 where the rest of the products in the suite are at V12.0?  This might indicate a lot of fixes or support issues in the near term. If it’s a reseller agreement, or company purchase, is there an issue with inter-product integration within the suite or licensing consistency? 
• In the case of a reseller agreement, what is the relationship with the company? Is there a risk that the agreement will terminate or the reseller will be bought by a competitor? (This happened a few years ago when a suite vendor was reselling a product from a small company that was bought by their competitor.  Many of the suite vendor’s clients lost technical support and update capabilities) Is the suite vendor on the resellers early adopter program? If not, you could be getting releases up to 6 months later than the reseller’s regular clients.
• Are there separate configuration, administration and reporting setups between products in the suite?  And of course marketeering a suite can be the worst as this generally means a bunch of disjointed products have been branded together without near term integration (I once said a company known for this tactic had just mapped a whiz-bang-refrigerator under their product suite brand).
• Are there competing products in the suite and which ones are in the roadmap for the long run? This brings up an interesting problem when the functionality an organization needs is in the product not on the long term roadmap.  I had a client that purchased a suite which worked with two different directories for access.  But when the component using the directories was dropped for a competing product in the suite, this capability was no longer supported.
• Who supports the individual products in the suite?  Does the suite vendor handle support for all the products? Or in the case of reseller agreements, does the original vendor support their product(s) in the suite?  I’ve heard horror stories from clients where there was an inter-product interoperability issue within a suite and both the suite vendor and product vendor continued to point fingers at each other saying, “It’s their problem.” while the issue continued with no resolution.
• If professional services are used, who delivers the product and trains the organization’s administrators?  Again, I’ve heard stories of small resellers doing installation and training for large suite vendors where there was only one person who was flying around the world doing all the installs, or the professional services personnel had lower standards of quality than the suite vendor’s professional services, or where the delivery people didn’t speak the local language even though the suite vendor had a large, local presence in that country.  Ask a lot of detailed questions about the professional services team’s capabilities if you find the product you’re interested in is new to the suite.

A non-disclosure meeting with the vendor is generally required to understand, the sometimes, complex relationship between the products under the common branding.

Best-in-class vs. suite products: Ok, once you understand how the suite was created and how the products within the suite interact, it’s time to think about whether you go with the suite or an individual product.  This elicits another set of questions for consideration.

• Do we have the personnel to do both end system integration and inter-product integration with the other solutions we have?  I had a client that went with a best-in-class solution instead of adding another product from the vendor’s suite they already had in place.  The main reason was cost.  It was $1M for the best-in-class product and $2M for the suite addition.  The problem, after the deployment they found they spent $5M just in inter-product integration with the existing products for special programs and custom interfaces that had to be developed in-house.  It also took 9 months longer to deploy than their estimate of how long it would have taken to do the suite product.  Pretty compelling to go with a suite, until you get to the next question….
• How good are the products within the suite?  Not all products in a suite are best-in-class.  Like a car dealer once explained to me, “When we purchase a lot of used cars we have to take a few junkers in order to get some nice ones.”  In evaluating a suite sometimes you have to “average” their capabilities.  One product might be #1 in its capabilities, another might be #3 and another may be #27.  If you go with best-in-class tools, assuming the integration and management of the individual products don’t kill you, you generally will have a set of tools with better functionality than a suite of products (something that’s important to the end users).

Finally, the question that needs to be asked in these economic times, how secure is the company if you go with their suite of products?  After all, you’re putting all your expertise, security of your organization, and money into a company you hope will be around, at least until you get promoted into another area of the organization or retire.  I know many people would never have guessed 10 years ago that Sun Microsystems would be on the selling block.  Security and identity management products still have a lot of boutique vendors.  I’ve actually recommended to a few very large clients that if they go with a single company for their security or identity management that one scenario that they should consider is just outright buying the company.  It sounds humorous but if you’re investing millions in a product from a company worth tens-of-millions, buying the company would be a lot cheaper than having them go under, ripping out all the products and putting in another product suite. Not to mention the downtime and loss of business while this all took place.

So are suites better?  Yes and no.  It’s up to the individual organizations to take a hard look at their support staff capabilities, the timing of when they need their deployments and how much ownership they want to put into making the products work as an infrastructure service.  If the organization can’t satisfactorily manage an infrastructure of individual products, a suite just might be up their alley.

r

The “Pearl Harbor Syndrome” (Inaugural Post)

 

Welcome to my personal blogging site on IT Security and Identity Management (separated in many organizations, but one in the minds of people tasked with the protection of information). 

As I open this blog looking at the state of protection in the world, I realize that with the downturn economy we’re creating an information landscape that as a “native Hawaiian” (yes, I was born there) is very familiar, Hawaii, 1941.  Back then the U.S. had brought its Pacific Fleet to Hawaii and ordered a military buildup in the Philippines in the hope of discouraging Japanese aggression in the Far East.  By showing the size and force of the U.S. military, the President had hoped that Japan would see that they had no way of winning against such a formidable foe.  If you think about it, this is exactly what many organizations are doing today to protect against information loss.  They’re following what I call the “Pearl Harbor Syndrome”, building up a suite of S/W and H/W solutions (i.e. Data Loss Protection (DLP) tools; building “hacker-proof” websites, portals and network channels; encrypting e-mails; provisioning tools to manage the life-cycle of employee responsibilities and privileges; etc.) in hopes of deterring people from conducting malicious activities against them.

But are all these technologies a deterrent to the “enemies” of the organization not to attack?  Not really.  The Japanese attacked with three objectives:

1)      Destroy American fleet units, thereby preventing the Pacific Fleet from interfering with Japanese conquest.

2)      Buy time for Japan to consolidate her position and increase her naval strength.

3)      Be a blow against American morale, which might discourage the U.S. into entering a war in the Pacific.

Today’s “enemies” have similar objectives

1)      Disable the security boundaries of an organization so they won’t interfere with their activities.

2)      Create “back doors” in the security technologies so they have time to infiltrate the corporate systems looking for valuable information.

3)      Attack the morale of the organization’s clients to weaken the company’s reputation, cause revenue loss, and keep the organization in a state of recovery.

So what mistakes did the U.S. do that you can learn from as you look at your “battleships” of protection? First, the lines of communication must be established.  The U.S. had people on the ground that saw the attack planes flying toward Pearl Harbor but didn’t have a way to get that information to the right people in a timely way.  And even when the information was given, the military was too arrogant to believe it because it didn’t come from their “official” sources.  I don’t know how many times I worked with an organization where I never saw a business person, a client, or an end user.  By partnering with the people who own, manage and use the information you want to protect, and providing a two-way communication channel with them, IT and security staff can have a tremendous number of eyes and ears to detect problems and attacks before they succeed. 

Knowing your weaknesses and strengths is important. The U.S. saw their battleships as the best deterrent technology available.  But the Japanese knew they were just large metal targets when confined within the harbor and exploited this with relatively simple, low cost mechanisms.  Having multi-million dollars of deterrent technologies without the proper environment and support needed will allow outsiders to exploit their weaknesses as well.  It takes time AND EFFORT to take advantage of all the protections these technologies provide.

Finally, put in place the contingency plans for an attack in now, not after they occur.  Too many organizations have found themselves in an unenviable position of having to deal with an attack without the tools in place to begin the forensic phase that follows.  Leaving yourself helpless also allows the attackers time to consolidate their position and increase their strength to do further damage.  In addition, government disclosure laws are forcing organizations to have formal plans so don’t wait.  In a recent conference I attended a presenter from the FBI suggested a “take a local FBI agent out to lunch” meeting where you can get to know the law enforcement officer and where they can get you started understanding what you can do to work with them.

Unfortunately the U.S. lost a lot of good people in the attack on Dec. 7, 1941 but they learned a lot of valuable lessons that day.  Hopefully you can learn from their mistakes and not have a “… date which will live in infamy” of the day your organization had a successful attack against it.

r