Tag Archives: Risk management

SOX IT Compliance

A customer case study – SOX IT Compliance

We performed a Sarbanes-Oxley IT top down security assessment for a NASDAQ-traded advanced technology company. The objectives for the study were to evaluate the internal and external threats that impact the company’s information assets. Using the Business threat modeling (BTM) methodology, a practical threat analysis PTA threat model was constructed and a number of threat scenarios were analyzed. Data was collected using structured interviews and network surveillance (with a Fidelis XPS appliance). Assets were valuated by the CFO and the IT security operations and technologies were valuated by the CIO. The output of the study was a cost-effective, prioritized program of security controls.This program was presented and approved by the management board of the company- leading to an immediate cost savings of over $120,000/year in the information security budget.

The detailed threat model was provided to the client and is currently used to perform what-if analysis and track the data security implementation. 

Download the data security case study and download the data security report to the management.

Conclusions

  1. The bulk of the security budget is currently spent on sustaining network perimeter security and system availability. Not surprisingly, these countermeasures are not particularly effective in mitigating insider threats such as lost or stolen hardware and information leakage, which now dominate the company’s risk profile.

  2. In corporate IT Security operations: The two major data security systems that were purchased in 2007, Imperva and Fidelis XPS Extrusion Prevention System have not yet been fully implemented and do not provide the expected benefit. To be specific, Imperva needs to be able to produce real-time alerts on violations based on logical combinations of OS user, DB application and DB user. Fidelis needs to be deployed in the subsidiaries. Monitoring from both systems needs to become a daily operational tool for the security officer.

  3. In the Asia Pacific region: Loss of notebooks to the tune of 2-3 / quarter is a major vulnerability although content abuse of the corporate network is assessed as negligible due to cultural factors.

  4. In general: Publicly facing FTP servers must be monitored carefully for violations of the company acceptable usage policy. In the course of the risk assessment, we discovered strategic plans and proprietary source codes that were stored on publicly accessible FTP servers.

Tell your friends and colleagues about us. Thanks!
Share this

10 guidelines for a security audit

What exactly is the role of an information security auditor?  In some cases, such as compliance  by Level 1 and 2 merchants with PCI DSS 2.0,  external audit is a condition to PCI DSS 2.0 compliance.   In the case of ISO 27001, the audit process is a key to achieving ISO 27001 certification (unlike PCI and HIPAA, ISO regards certification, not compliance as the goal).

There is a gap between what the public expects from an auditor and how auditors understand their role.

Auditors look at transactions and controls. They’re not the business owner and the more billable hours, the better.

The “reasonable person” assumes that the role of the security auditor is to uncover vulnerabilities, point out ways to improve security and produce a report that will enable the client to comply with relevant compliance regulation. The “reasonable person” might add an additional requirement of a “get out of jail free card”, namely that the auditor should produce a report that will stand up to legal scrutiny in times of a data security breach.

Auditors don’t give out “get out of jail” cards and audit is not generally part of the business risk management.

The “reasonable person” is a legal fiction of the common law representing an objective standard against which any individual’s conduct can be measured. As noted in the wikipedia article on the reasonable person:

This standard performs a crucial role in determining negligence in both criminal law—that is, criminal negligence—and tort law. The standard also has a presence in contract law, though its use there is substantially different.

Enron, and the resulting Sarbanes-Oxley legislation resulted in significant changes in accounting firms’ behavior,but judging from the 2009 financial crisis from Morgan Stanley to AIG, the regulation has done little to improve our confidence in our auditors. The numbers of data security breaches are an indication that the situation is similar in corporate information security.  We can all have “get out of jail” cards but data security audits do not seem to be mitigating new risk from tablet devices and mobile apps. Neither am I aware of a PCI DSS certified auditor being detained or sued for negligence in data breaches at PCI DSS compliant organizations such as Health Net where 9 data servers that contained sensitive health information went missing from Health Net’s data center in Rancho Cordova, California. The servers contained the personal information of 1.9 million current and former policyholders, compromising their names, addresses, health information, Social Security numbers and financial information.

The security auditor expectation gap has sometimes been depicted by auditor organizations as an issue to be addressed  by educating users to the audit process. This is a response not unlike the notion that security awareness programs are effective data security countermeasures for employees that willfully steal data or bring their personal device to work.

Convenience and greed tend to trump awareness and education in corporate workplaces.

Here are 10 guidelines that I would suggest for client and auditor alike when planning and executing a data security audit engagement:

1. Use an engagement letter every time. Although the SAS 83 regulation makes it clear that an engagement letter must be used, the practical reason is that an engagement letter sets the mutual expectations, reduces risk of litigation and by putting mutual requirements on the table – improves client-auditor relationship.

2.Plan. Plan carefully who needs to be involved, what data needs to be collected and require input from C-level executives to  group leaders and the people who provide customer service and manufacture the product.

3. Make sure the auditor understands the client and the business.  Aside from wasted time, most of the famous frauds happened where the auditors didn’t really understand the business.   Understanding the business will lead to better quality audit engagements and enable the auditor and audit manager to be peers in the boardroom not peons in the hallway.

4. Speak to your predecessor.   Make sure the auditor talks to the people who came before him.  Speak with the people in your organization who did the last data security audit.   Even if they’ve left the company – it is important to understand what they did and what they thought could have been improved.

5. Don’t tread water. It’s not uncommon to spend a lot of time collecting data, auditing procedures and logs and then run out of time and billable hours, missing the big picture which is” how badly the client organization could be damaged if they had a major data security breach”. Looking at the big picture often leads to audit directions that can prevent disasters and  subsequent litigation.

6. Don’t repeat what you did last year.  Renewing a 2,000 hour audit engagement that regurgitates last years security check list will not reduce your threat surface.  The objective is not to work hard, the object is to reduce your value at risk, comply and …. get your “get out of jail card”.

7. Train the client to fish for himself.   This is win-win for the auditor and client. Beyond reducing the amount of work onsite, training client staff to be more self sufficient in the data collection and risk analysis process enables the auditor to better assess client security and risk staff (one of the requirements of a security audit) and improves the quality of data collected since client employees are the closer to actual vulnerabilities and non-compliance areas than any auditor.

As I learned with security audits at telecom service providers and credit card issuers, the customer service teams know where the bodies are buried, not a wet-behind-the-ears auditor from KPMG.

8. Follow up on incomplete or unsatisfactory information.  After a data security breach, there will be litigation.  During litigation, you can always find expert testimony that agrees with your interpretation of information but

The problem is not interpreting the data but acting on unusual or  missing data.  If your ears start twitching, don’t ignore your instincts. Start unraveling the evidence.

9. Document the work you do.  Plan the audit and document the process.  If there is a peer review, you will have the documentation showing the procedures that were done.  Documentation will help you improve the next audit.

10. Spend some time evaluating your client/auditor.   At the end of the engagement, take a few minutes and interview your auditor/client and ask performance review kinds of questions like: What do think your strengths are, what are your weaknesses?  what was succesful in this audit?  what do you consider a failure?   How would you grade yourself on a scale of 10?

Perhaps the biggest mistake we all make is not carefully evaluating the potential we have to meet our goals as audit, risk and security professionals.

A post-audit performance review will help us do it better next time.

Tell your friends and colleagues about us. Thanks!
Share this

Giving ISO 27001 business context

ISO 27001 is arguably the most comprehensive information security framework available today. Moreover, it is a vendor neutral standard. However – ISO 27001 doesn’t relate to assets or asset value and doesn’t address business context which requires prioritizing security controls and their costs.  This article discusses the benefits of performing an ISO 27001 based risk assessment exercise using techniques of threat modeling.  An organization that follows this methodology will reap the benefits of improved data security and achieving readiness for ISO 27001 certification.

Why is threat analysis beneficial for ISO 27001?

Quantitative threat analysis using the popular PTA (Practical Threat Analysis) modeling tool provides a number of meaningful benefits for ISO 27001 risk assessments:

  • Quantitative: enables business decision makers to state asset values, risk profile and controls in familiar monetary values. This takes security decisions out of the realm of qualitative risk discussion and into the realm of business justification.
  • Robust: enables analysts to preserve data integrity of complex multi-dimensional risk models versus Excel spreadsheets that tend to be unwieldy, unstable and difficult to maintain.
  • Versatile: enables organizations to reuse existing threat libraries in new business situations and perform continuous risk assessment and what-if analysis on control scenarios without jeopardizing the integrity of the data.
  • Effective: helps determine the most effective security countermeasures and their order of implementation, saving you money.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this

Understanding culture and security

Whether you’re an account manager at Cisco, a programming geek in an Israeli startup, an expert on PCI DSS 2.0 or an industry authority on CRM; you must understand the culture in your workplace in addition to your professional skills in order to effectively manage risk and comply with regulation. If you alienate people – you won’t be able to improve security and compliance.


I was reminded of the importance of understanding culture in security and compliance  by a story related to me by my friend Issac Botbol, who is a professional leadership development trainer (see his web site : IB Communication Skills )

A few years ago, when I worked at Intel Fab8 in Jerusalem, we were chosen to train about 150 engineers for the Intel fab in Leixlip Ireland. I had two Irish people on my team. In particular, I remember Ronnie and Dympna (she told me – pronounce my name like “Debna”, you know like the DEC network adapter…) Dympna once worked for Digital Equipment Corporation and I spent years developing applications in VAX/VMS so we shared common language, the language of Digital networking equipment.

Before the Irish people came on board, the Israelis went through 3 days of cross-cultural training. We learned a lot, including how much Israelis and Irish are alike – strong family values, ties to country, religion (but not too much) and openness. Of course, the Irish can drink us under the table – which is probably why we had a great 6 months together.

There is a famous but true story about a Texas oil company that was intensely involved in negotiating a substantial business deal with a major company in Mexico. The American team spared no expense in flying their experts to Mexico and presenting the benefits and long term rewards of their state of the art equipment, hardware and excellent customer support. Throughout the negotiations and long hours of working together, both the Mexican and American teams developed a camaraderie and respect for each other.

The Mexicans were satisfied with the proposal and agreed to proceed with the deal. The Americans were delighted. They phoned their legal department in Houston and instructed them to fax the contract to their Mexican counterparts. Since they felt they had completed their job the American team jumped on the next flight back home.

The Mexicans were incensed! They wondered how the American team could be so rude and insensitive as to just fax a bunch of papers and expect to seal such an important deal after weeks of working closely together. The Mexican team refused to sign the contact tried to have as little contact as possible with the American team.

Eventually, when the Americans inquired about the delay and discovered what had happened, they immediately went into damage control. For the American negotiating team, the signing of the deal meant the final phase of a process. For the Mexicans, it symbolized the beginning of a relationship. They wanted to celebrate this milestone and make it personal. They wanted this important occasion to be marked by having all the major players and their spouses, from both sides of the border, to come together and enjoy a memorable dinner.

Fortunately, this story has a happy ending because the American team was able to recover and the deal was finally signed. The lesson from this incident is quite significant because it teaches us the importance of being aware of the different cultural perspectives. While the American business stance is to be task and results oriented, the Hispanic mindset places much more emphasis on the human side of business.

When dealing with customers in Europe (especially Italy, Israel and Greece) this lesson is just as valuable. Hi-tech sales and technology management is also about understanding the cultural differences. Whether they’re your customers, colleagues or direct reports – people want to see the business as well as the human side of your leadership abilities. They want to know that despite the language differences, you genuinely care about them and the work they do. Of course this is true in every workplace but driving home this idea and putting into practice, is much more difficult and challenging when there are different language and cultural expectations.

Tell your friends and colleagues about us. Thanks!
Share this

Taking security on the offensive

I believe many people involved with IT security have a feeling of frustration that stems from continously reacting to external forces: spam attacks, spyware attacks, insider threats, analyst reports and new product announcements. Is it possible to be an information security officer and mitigate threats to confidentiality, availability and integrity of data in a proactive fashion?


Well, step back and consider three basic tenets of IT Security

  • Information Security is Warfare.
  • Most of your information security strategy is reactionary with “Penetrate and Patch” methods
  • Few implementations address the collection of information about attackers.

The key Elements in Information Security Strategy

I propose to stop reacting and go back on the offensive, with a proactive security strategy based on control, collection, capture and change:

Control: Managing the access of information to and from the network and systems.
Collection: Gathering information about user habits and systems behavior.
Capture: The capture of information from anomalous events on the network.
Change: Adapt the security posture to meet new situations.

By basing both defensive and offensive tactics on these four strategic elements, you can poractively control who accesses your network, collect information about abnormal transactions, capture anomalous events, and adapt your security posture to meet changing situations.

Defensive Information Security Tactics

  • Network Access Control.
  • Host Access Control.
  • Intrusion Prevention Systems
  • Data loss prevention (DLP)
  • Application firewalls
  • Backups

Offensive Information Security Tactics

  • Honey Pots and Honey Nets.
  • Attacking and auditing your own systems.
  • Proactive response to attacks.

Acknowledgement: Christopher Neitzert (Chris@Neitzert.com) who was the first to delve into how to improve information security with a combination of both offensive and defensive tactics.

Tell your friends and colleagues about us. Thanks!
Share this

Protecting your data in the cloud

Several factors combine to make data security in the cloud a challenge.

Web applications have fundamental vulnerabilities. HTTP is the cloud protocol of choice for everything from file backup in the cloud to Sales force management in the cloud. HTTP and HTML evolved from a protocol for static file delivery to a protocol for 2 way applications – a purpose for which they  were never designed; let’s examine some of the data security issues with the current rich content Web 2.0 model:

1. The multiple layers at the server side from db server to Web server or App server are vulnerable to attack since the Web application passes messages to the data tier through several interfaces in order to execute SQL.  The interfaces are vulnerable, in particular to SQL injection

2. HTTP is a stateless protocol. As a result, the simplest kind of Ajax application generates dozens of http transactions between the client and the server. The simplest autocomplete floods the pipe with Ajax transactions.  If you have ever put a sniffer like Wireshark on the line you will see this.  The rich interactivity on the client with Ajax generates a huge, disproportionate amount of traffic and a high price tag for simple operations.   For example – in a tcp socket-socket link, if you want to know if there are new mail messages, no polling is required and the message length is just a few bytes. This is primarily a latency and load issue on the cloud computing infrastructure but also creates additional difficulties in detecting data loss and opens the door for network-based attacks such as a slow POST DDOS attack.

3. Passing messages between remote process (client and server) inside the query string is patently a bad idea that is not remedied by using https (although if you pass privacy data in a query string you must use https). It is a bad idea because it is fragile (may break on software changes) and vulnerable to any number of software bugs and exploits from buffer overflow to sql injection to simple query hacking.  To get a feel for the order of magnitude of the problem, just google for web application security.

The current rich Web 2.0 model is broken, not because Javascript or PHP are bad, it’s just that the existing Web application stack on server and client is a bad fit to the world of applications.

There is little free market demand for software security. The key demand-side driver for cloud computing is that it is a service that can be consumed at a  variable cost like a utility. We might think that with all the headlines on data security breaches,  that consumers would be discerning about the security of the service.  However,  data loss risk is negligible in a consumer buying decision since people use applications based on their utility and productivity and beauty of the UI not because of their security, since we all assume that the security is built-in.  The cloud model requires the consumer to consider impact of data loss, similar to considering the impact of a power spike on home appliances with digital controllers.  Data security in the cloud won’t happen by itself.

Enforcing data security in the cloud is harder than in the enterprise. Trusted insiders can exploit application vulnerabilities no matter where the application runs.  However, our ability to detect data loss inside the cloud is far less than our ability to detect data loss inside an office network and more expensive to mitigate in a virtualized operating system environment.

Inside an enterprise network, you can put procedural, network monitoring and DLP solutions into place, however the same security countermeasures may not be supported by your cloud provider as a standard item.   By implementing custom countermeasures in the cloud, you won’t enjoy the economy of scale of a shared, virtualized infrastructure nor benefit from the experience curve of the cloud service provider.  It will become your problem.

Data security is about economics. If you want guaranteed service levels on the security of your IP and customer data that you store in a SaaS system, you need to RFP and negotiate the appropriate contract and security countermeasures (encrypting data at rest and in motion, employee monitoring, key management, data loss prevention, malicious software detection and more).  Compliance with PCI DSS 2.0 and HIPAA may come at additional cost.

Data security in the cloud is a cost borne upstream by the customer and downstream by the cloud provider.

From a cloud service provider perspective, note that there are high fixed costs involved in providing capacity, customer support and secure infrastructure while the revenue from consumers is variable. Consumers that adopt a hybrid model for cloud delivery will have additional fixed and variable costs of operation.

In order to protect your data in the cloud, I suggest adopting some common-sense best practices:

  • Before moving your application to the cloud, do some attack modeling and consider the value of your assets to be stored in the cloud, versus the cloud service costs and custom security measures you may (or may not need) to implement
  • Invest in software security. Remember that hackers attack your software, not your security procedures.
  • After you set a budget, choose a cloud service according to your threat model and read their dotted line on data security before committing
Tell your friends and colleagues about us. Thanks!
Share this

Making security live in a performance culture

In a recent PCI seminar I attended,  the speaker (who hails from the European PCI Security Council) claimed that most European businesses were in a very bad place in terms of their data security but that that the ultimate business objective is 100 percent compliance. I’ve heard similar pronouncements from industry analysts like Forrester.

This is problematic for a number of reasons, starting with the fact that it is impossible to be 100 percent compliant with this or any other standard. A business lives in a performance culture whereas regulators live in a compliance culture. Compliance does not contribute to improving business performance unless the compliance activity is used as an opportunity to improve product security and customer safety and reduce the cost of current security measures.  This is definitely the path you want to choose – forcing your compliance exercise into the same performance mold that your business values and not settling for less.

In a compliance culture

  • I comply with the standard.
  • I am told the standard. If I am not told, I don’t act.
  • The standard is my objective.
  • When I meet the standard, I am done.

In a performance culture

  • My job is to take risks and deliver value by performing and executing ahead of expectations
  • A standard is like a quota.  Something you want to exceed because next year it will be higher.
  • Meeting a standard means little. I continuously improve.
Tell your friends and colleagues about us. Thanks!
Share this

Why Rich Web 2.0 may break the cloud

There are some good reasons why cloud computing is growing so rapidly.

First of all there are  the technology enablers: Bandwidth and computing power is cheap. Software development is more accessible than ever. Small software teams can develop great products and distribute it world wide instantly.

But cloud computing goes beyond supply-side economics and directly to the heart of the demand-side – the customer who consumes IT.

Consuming  computing as a utility simplifies life for a business. It’s easy to understand (unlike data security technology) and it’s easy to measure economic benefit (unlike governance, risk and compliance activities).

Cloud computing is more than an economic option; it’s also a personal option. Cloud computing is an interesting, almost revolutionary consumer alternative to internal IT systems due to it’s low cost and service utility model.

Current corporate IT  operations provide services to  captive “users” and empower management (historically, information technology has its roots in MIS – management information systems).  When IT vendors go to market, they go to the CxO executives. All the IT sales training and CIO strategies are based on empowering management and being peers in the boardroom. Sell high, don’t sell low. After all, employees don’t sign checks.

But cloud computing is changing the paradigm of top-down, management-board decision-based IT. If you are a sales professional and need a new application for your business unit,  you can acquire the application like a smart phone and a package of minutes. Cloud computing is a service you can buy without a corporate signature loop.

An employee in a remote sales office can sign up for Salesforce.com ($50/month for 5 sales people) or Google Apps (free up to 50 users) and manage software development on github.com (free for Open Source).

So far – that’s the good news. But – in the Cloud of rich Web 2.0 application services, we are not in Kansas anymore.  There is a very very good reason to be worried. With all the expertise of cloud security providers – the Web 2.0 service they provide is only as secure as the application software itself.

The current rich Web 2.0 application development and execution model is broken.

Consider that a Web 2.0 application has to serve browsers and smart phones. It’s based on a heterogeneous server stack with 5-7 layers (database, database connectors, middleware, scripting languages like PHP, Java and C#, application servers, web servers, caching servers and proxy servers.  On the client-side there is an additional  heterogeneous stack of HTML, XML, Javascript, CSS and Flash.

On the server-side, we have

  • 2-5 languages (PHP, SQL, tcsh, Java, C/C++, PL/SQL)
  • Lots of interface methods (hidden fields, query strings, JSON)
  • Server-side database management (MySQL, MS SQL Server, Oracle, PostgreSQL)

On the client side, we have

  • 2-5 languages ((Javascript, XML, HTML, CSS, Java, ActionScript)
  • Lots of interface methods (hidden fields, query strings, JSON)
  • Local data storage – often duplicating session and application data stored on the server data tier.

A minimum of 2 languages on the server side (PHP, SQL) and 3 on the client side (Javascript, HTML, CSS) turns developers into frequent searchers for answers on the Internet (many of which are incorrect)  driving up the frequency of software defects relative to a single language development platform where the development team has a better chance of attaining maturity and proficiency. More bugs means more security vulnerabilities.

Back end data base servers interfaced to front end scripting languages like C# and PHP comes built-in with vulnerabilities to attacks on the data tier via the interface.

But the biggest vulnerability of rich Web 2.0 applications is that  message passing is performed in the UI in clear text – literally inviting exploits and data leakage.

The multiple interfaces,  clear text message passing and the lack of a solid understanding of how  the application will actually work in the wild guarantee that SQL injection, Web server exploits, JSON exploits, CSS exploits and application design flaws that enable attackers to steal data will continue to star in today’s headlines.

Passing messages between remote processes on the UI is a really bad idea, but the entire rich We 2.0 execution model is based on this really bad idea.

Ask a simple question: How many ways are there to pass an array of search strings from a browser client to a Web server? Let’s say at least two – comma-delimited strings or JSON-encoded arrays.  Then ask another question – do Mozilla (Firefox), Webkit (Chrome) and Microsoft IE8 treat client data transfer in a uniform, vendor-neutral standard way?  Of course not.   The list of Microsoft IE incompatibilities or different interpretations of W3C standards is endless.   Mozilla and Webkit  transmit UTF-8 url-encoded data as-is in a query string sent to the server. But, Microsoft IE8 takes UTF-8 data in the query string and converts it to ? (yes question marks) in an XHR transaction unless the data has been previously uri-encoded.   Are browser incompatibilities a source of of application bugs? Do these bugs lead to software security vulnerabilities?  Definitely.

So, it’s really easy to develop cool Web 2.0 applications for seeing who’s hot and who’s not. It’s also cheap to deploy your totally-cool social networking application on a shoestring budget. Facebook started with a budget of $9,000 and so can you.

But, it’s also totally easy to hack that really cool rich Web 2.0 application, steal personal data and crash the system.

A standard answer to the cloud security challenge is writing the security into the contract with the cloud service provider.

Consider however,who is the customer of that cool social media application running in the cloud on some IaaS (infrastructure as a service). If you are a user of a cool new free application, you cannot negotiate or RFP the security issues away, because you are not the customer.  You generate content for the advertisers, who are the real customers.

With a broken development and execution model for rich Web 2.0 applications, the cloud computing model of software as a service utility is not sustainable for all but the largest providers like Facebook and Salesforce.com.   The cost of security is too high for the application provider and the risk of entrusting valuable business IP  and sensitive customer data to the cloud is unreasonable. Your best option is to hope that your cool Web application will succeed small-time, make you some cash and enable you to fly under the radar with a minimal attack surface.

Like your first girl friend told you – it’s not you, it’s me.

It’s not the IT infrastructure, it’s the software.

Tell your friends and colleagues about us. Thanks!
Share this

What is security?

So what is security anyhow?

Security is not about awareness.

A lot of folks talk about the people factor and how investing in security awareness training is key for data protection.

I think that investing in formal security awareness training, internal advertising campaigns and all kinds of fancy booklets and cards for employees is a waste of time and money.  I prefer a  CEO that says “here are my 4 rules” and tells his staff to abide by them, who tell their direct reports to abide by them until it trickles down to the people at the front desk.  Making common sense security part of the performance review is more effective than posters and HR training.

Security from this perspective, is indeed an exercise in leadership. Unfortunately, in  many organizations, the management board sees themselves as exempt from the information security rules that they demand from their middle managers and employees. It might be a general manager bringing his new  notebook into the office, jacking into the corporate LAN and then attaching a wireless USB dongle effectively bridging the corporate network to the Internet with a capital I, not understanding and not really caring about the vulnerability he just created.

Security is not an enterprise GRC system

If you take a look at the big enterprise GRC systems from companies like Oracle – you see an emphasis placed on MANAGING THE GRC PROCESSES – document management and signature loops for ISO certification, SOX audits etc. I suppose this makes the auditors and CRO and Oracle salesperson happy but it has nothing to do with making secure software. In my world – most hackers attack  software, not audit compliance processes and GRC documentation. In other words – managing  GRC processes is a non-value add for security.

Security doesn’t improves your bottom line
Have you ever asked yourself why security is so hard to sell?

There are two reasons.

1) Security is  complex stuff and it’s hard to sell stuff people dont understand.

2). Security is about mitigating the impact of an event that might not happen, not about making the business operation more effective.

Note a curious trait of human behavior  (formalized in prospect theory – developed by Daniel Kahneman and Amos Tversky in 1979), that people (including managers who buy security) are risk-averse over prospects involving gains, but risk-loving over prospects involving losses.

In other words – a CEO would rather take the risk of a data breach (which might be high impact, but low probability) than invest in DLP technology that he does not understand. Managers are not stupid – they know what needs to be done to make more money or survive in a downturn. If it’s making payroll or getting a machine that makes widgets faster for less money – you can be sure the CEO will sign off on making payroll and buying the machine before she invests in that important DLP system.

Since almost no companies actually maintain security metrics and cost of their assets and security portfolio in order to track Value at Risk versus security portfolio over time – a  hypothesis of return on security investment cannot be proven. Indeed – the converse is true – judging by the behavior of most companies – they do not believe that security saves them money

So what is security?

It’s like brakes on your car. You would not get into a car without brakes or with faulty brakes. But brakes are a safety feature,  not a vehicle function that improves miles per gallon. It’s clear that a driver who has a lighter foot on the brakes will get better mileage, and continuing the analogy, perhaps spending less money on security technology and more on security professionals will get you better return on security investment.

Challenge your assumptions about what makes for effective security in your organization.  Is enterprise security really about multiple networks and multiple firewalls with thousands of rules? Perhaps a simpler firewall configuration in a consolidated enterprise network is more secure and cheaper to operate?

Tell your friends and colleagues about us. Thanks!
Share this

The case for a guild of security consultants

The notion of a security consultant guild is a seductive idea.  Promoting  quality, defining service levels and enhancing professional standing are good  things, but there is a red ocean of professional forums so – I would not just jump in and start a guild.

Just take a look at forums like LinkedIn and Infosec Island – most (sometimes it feels like all…) of the folks in professional networks are independent  consultants – and that makes perfect sense – we all have to eat. Yet LinkedIn cannot replace industry forums like ISACA or ISC2 that work to promote industry standards, improve security awareness, drive private-public partnerships etc.

The problem with ISC2 and similar industry lobbies – is that they have vested interests, therefore they don’t or can’t represent independent security consultants.  When was the last time Raytheon called me up – asking to collaborate on a data security project for DoD – like never?

I would take some lessons from the IETF.

Any security consultant organization should have three principles: free, open, and based on vendor-neutral standards.

Note my emphasis on “Vendor-neutral standards”.  This is the secret of the success of the IETF and the Internet in general and it will be the core of the success for any group of security consultants that want to do more than kibitz in LinkedIn security forums.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this