Tag Archives: business threat modeling

Why data security is like sex

We all think about sex – men (most of the time), women (some of time) and teenagers (all the time).

Sex – despite the huge volume of content in the digital and print media, is one of those phenomena that demonstrate an inverse relationship between substance and talk.    The more talk, chances are, the less substance actually going on. The less talk, the higher a probability that something serious is really going on between you and your partner.  When things are cooking for you and your wife/girl friend  you don’t have time to be writing about it on your blog. When things are rough,  you will probably be a bit shy about going into detail on Facebook.  But it’s a lot easier to talk about other people, who’s hot and who’s not.

Just like data security and global terror.  It’s a lot easier to talk about the Middle East and ignore what’s happening in your own backyard.   It’s like  “other peoples money” – something you can spend without worrying too much.

Using this metaphor, the data security industry is like sex.   Lots of talk and press releases about data breaches, plenty of marketing communications written by clueless communications majors just out of school working for Symantec and Mcafee and recycling of Gartner reports ad nauseum.  But – a lot less in the vulnerability and risk mitigation department and generally low levels of willingness to talk about security failures in an organization or what really works.

Since this is part of the human chemistry – I don’t imagine this will change in the near future but for sure we will have a lot of fun, just like great sex.

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

Software security assessments

In a way, every software security assessment is an exercise in software development. The first step in the software security assessment project is requirements analysis. Requirements analysis is concerned with what the system (whether it be a “traditional” application or a rich Web 2.0 application for social networking) needs to do. This involves examining the requirements of the business itself, the users of the application against the backdrop of cost and engineering constraints such as throughput and response time when the application is deployed on a cloud computing platform.

Business Requirements

  • Business Requirements analysis – Describe the business and its it’s customers, suppliers and users, problems, issues and expectations. This is essential when developing a new application, but also crucial when you’’re making significant changes to an application. “Why” do you want to develop the software and “how much” is it going to cost? Is there a ROI (return on investment). Can your team develop and implement the product?
  • P.I.E – – Problems Issues and Expectations – Describe current problems and put the issues and expectations that users have in the current environment into separate categories. An expectation may be crucial to success of the project or it may be a “user satisfaction” feature that can be postponed to Revision 9.5
  • Causes and Consequences – Discuss causes of current system problems and their consequences. You will discover that a problem’s result is often a problem in it’s own right. You need to drill down to the root cause of the problem peeling away the symptoms.
  • Target system tasks – Discuss and observe users as they work with the software application. Remember that the important things are (a) how easy it is to install/start using a product (b) how fast it works and c) how intuitive is the UI. This is particularly relevant to Web-based applications, where the user experience will make or break the application.
  • System Design Alternatives Analysis – Very few systems are new. In alternatives analysis you will consider the strengths and weaknesses of existing approaches including not doing the project at all.

Software security requirements

A business requirements analysis is not enough to ensure that a system meets the real needs of its users or that it will ever succeed in the real world as a product. In fact, reducing a system specification to a set of required functions, without regard to how the functions are used or how they will be implemented in real hardware/software by real people is a guarantee for failure . The design of a new system or major change will usually involve the following steps:

  • Task Decomposition – Business requirements are broken down and mapped into software and hardware modules and features.
  • User stories– A “user story” corresponds to a feature of a system module. Stories are small, typically limited by an estimate to implement the software for a story by one programmer working for one week. The user story needs to stay in sync with the business requirements – and stay away from gold-plating.
  • Data Modeling – Data modeling describes the data elements in the assessed system and the relationships between the data elements. Done in parallel to developing the “user stories” and ensures that the data needed to do the job is on the model.
  • User Interface Design – The user interface needs to be considered at an early stage in the software security assessment cycle. Functional requirements are combined with the knowledge gathered about users and contexts of use to provide the most appropriate methods of interaction.
  • Incremental assessment by prototyping – Assess a little piece of the system with selected routines and a  UI.  Security assessment prototyping allows vulnerability hypotheses to be tested, with resulting feedback incorporated into an iterative process of software defect reduction. Early prototypes may be purely paper-based to test the design or using a the application to test the software in vitro.
Tell your friends and colleagues about us. Thanks!
Share this

The 7 deadly sins of software security

Companies spend millions on compliance, but proprietary assets are still getting ripped off by insiders and hackers who compromise buggy, poor-designed applications. Here are 7 software development mistakes you don’t want to make in 2011.

7. Don’t KISS

If my experience is any indication – the software industry as a whole is wasting hundreds of millions of dollars a year by not Keeping It Simple. For example, complex technologies like Java J2EE are not warranted for the majority of Web applications. In my experience PHP is simpler to program and maintain, and scales well at a reasonable price – witness the millions of Yahoo pages are served by PHP each day. Lack of KISS is the main reason for high-costs, late schedules, failed projects and unsecure software that no one can maintain. When a programmer uses a component and doesn’t know it works (see EJBQL and CMP 2.0) and has to shlep around a lot of piping (look at an Eclipse project for a 3 tier J2EE project) then the energies go into implementation instead of thinking about code threats. It’s sort of like Microsoft Powerpoint, where you spend 80% of your time in the application’s GUI instead thinking about and then just stating your message.

Seems to me that the industry is trading off simpler, reliable and secure programming for fashion and features (J2EE,XP…)

6. Mismanage software development

The classic The Mythical Man-Month, written 20 years ago said that projects based on per-unit “man-months” usually dont work due to the unique nature of software development. The difference in productivity between the best programmer and an average guy is 100x. This means that 5 nwe college grads are inferior to solid programmer who knows what she’s doing. You are always better off with a few talented programmers than a large cast of average developers, a) because of individual productivity differentials and b) because smaller groups are always more effective.

This general observation is relevant to our case since the average developer construes O/S security with applying patches and application security with having an application firewall. Truth be told, it only takes one page of best practices for a Web application programmer not to allow SQL injection, long URLs, arbitrarily long input strings or directory traversal.

5. Take a wrong turn with outsourcing

Don’t outsource something just because it’s too hard to understand or you’re in a rush to market. A server clustering system offered by a major vendor was ported a while back to Linux by a team in India. The Indian market was booming and job loyalty was low, like Israel and Silicon Valley in the 90’s. In addition, due to transportation and cultural issues the work day was a fixed 8 hours not a “finish before you go home/never break the build” philosophy. The software was ported and is being delivered to customers with cryptic documentation, patch on patch on patch, multiple options to perform the same function (only one of which may be right, so the customer has to guess because documentation is unclear) and brittle functionality – a small change in configuration files can break the cluster.

Brittleness and poor documentation force the user to rely on strict manual operational procedures which depend on people which creates operational vulnerability.

4. Promote or hire the wrong people

I could write a book about this one. One common case is the excellent technologist who is promoted (desiring the job) into a managerial spot. He doesn’t have the people skills, won’t admit failure and can’t visualize going back to his old programmer slot. Another common case is hiring an ex-military guy to run a young engineering team. Six months later after the team has quit, your CEO will realize that you can’t hand orders to programmers like soldiers and you can’t flirt with the lady engineers and ask them to fetch the boss coffee.

The people who manage the teams have to have the art of software building and people building.

3. Decide based on religious beliefs

I know a company that decided on Open Source and Linux, going with a leading commercial distribution and a large systems integrator believing that the combination of Open Source and big-name vendors would guarantee success. The integrator’s skill set was primarily Windows, the distro vendor could care less about the fundamental flaws in the client’s design,and the company didnt have enough inhouse know-how of tool chain and Linux and couldn’t properly audit the progress and assess the problems of his contractor. Fortunately the project failed. I hate to think what would have happened if they would have succeeded in shipping the product – a SOHO security appliance with a Web interface for remote configuration.

The project spec must fit the system requirements; dont convert the system requirements to your religious beliefs.

2. Ignore internal system threats

Sales people know that sometimes their biggest competitors in closing a deal with a customer are people inside the company. For developers, this means that the programmer and her boss need to do a threat analysis from day 1 on the system taking into account backdoors, possible misuse, hard-coded parameters that can be forgotten or hacked later on and so forth. Temporary ftp servers for file transfer turn into permanent arrangements and vulnerability.

The team has to think about who will install, integrate and maintain the system even before considering operational issues.

1. Permit weak passwords

Threats such as worms get top PR but dont miss a basic IT mistake: weak authentication or bad passwords. Common password vulnerabilities include weak passwords (birthdays),publicly displayed passwords on Post-its, and Intranet and administrator passwords that the whole company knows. At my last company, people thought I had a great memory while in truth, just by working with the person; I could quickly and correctly guess the password to their workstation or servers. Later, after the team delivers the software, an external system integrator is often involved for installation at customer sites.

It is the responsibility of the developers to ensure that the system integrator will NOT be able to install the file transfer process between the AS400 and the billing system with anonymous ftp. I’m a fan of passphrases, I think they’re easier to remember and harder to crack but at the end of the day, passwords or passphrases need to be treated like cash. If you must, write them down on a piece of paper and save it your wallet. Dont store them on your Palm or save a file called system_passwords.xls in the MyDocuments folder of a PC in the computer room.

What should you do?

The software development environment of 20 years ago is radically different today. Development tools are free, hardware is almost free (think about those $100k Sun Enterprise 450 boxes and $500 Sun Ethernet NICS) and programming talent is a global resource. Its so easy to do things today but thats precisely the problem.
A development team can do but there is no replacement for a program/team manager that manages and directs the team away from the mistakes consistently.

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

Small business data security

Here are 7 steps to protecting your small business’s data and and intellectual property in 2011 in the era of the Obama Presidency and rising government regulation.

Some of these steps are about not drinking consultant coolade (like Step # 1- Do not be tempted into an expensive business process mapping project) and others are adopting best practices that work for big business (like Step #5 – Monitor your business partners)

Most of all, the 7 steps are about thinking through the threats and potential damage.

Step # 1- Do not be tempted into an expensive business process mapping exercise
Many consultants tell businesses that they must perform a detailed business process analysis and build data flow diagrams of data and business processes. This is an expensive task to execute and extremely difficult to maintain that can require large quantity of billable hours. That’s why they tell you to map data flows. The added value of knowing data flows between your business, your suppliers and customers is arguable. Just skip it.

Step #2 – Do not punch a compliance check list
There is no point in taking a non-value-added process and spending money on it just because the government tells you to. My maternal grandmother, who spoke fluent Yiddish would yell at us: ” grosse augen” (literally big eyes) when we would pile too much food on our plates. Yes, US publicly traded companies are subject to multiple regulations. Yes, retailers that  store and processes PII (personally identifiable data)  have to deal with PCI DSS 2.0, California State Privacy Law etc. But looking at all the corporate governance and compliance violations, it’s clear that government regulation has not made America more competitive nor better managed.  It’s more important for you to think about how much your business assets are worth and how you might get attacked than to punch a compliance check list.

Step #3 – Protecting your intellectual property doesn’t have to be expensive
If you have intellectual property, for example, proprietary mechanical designs in Autocad of machines that you build and maintain, schedule a 1 hour meeting with your accountant  and discuss how much the designs are worth to the business in dollars. In general, the value of any digital, reputational, physical or operational asset to your business can be established fairly quickly  in dollar terms by you and your accountant – in terms of replacement cost, impact on sales and operational costs.  If you store any of those designs on computers, you can get free open-source disk encryption software for Windows 7/Vista/XP, Mac OS X, and Linux. That way if there is a break-in and the computer is stolen, or if you lose your notebook on an airport conveyor belt, the data will be worthless to the thief.

Step #4 – Do not store Personally identifiable information or credit cards
I know it’s convenient to have the names, phone numbers and credit card numbers of customers but the absolutely worst thing you can do is to store that data. VISA has it right. Don’t store credit cards and magnetic strip data. It will not help you sell more anyway, you can use Paypal online or simply ask for the credit card at the cash register.  Get on Facebook and tell your customers how secure you are because you don’t store their personal data.

Step #5 – Don’t be afraid of your own employees, but do monitor your business partners
Despite the hype on trusted insiders, most data loss is from business partners. Write a non-disclosure agreement with your business partners and trust them, and audit their compliance at least once a year with a face-to-face interview.

Step #6 – Do annual security awareness training but keep it short and sweet
Awareness is great but like Andy Grove said – “A little fear in the workplace is not necassarily a bad thing”. Have your employees and contractors read, understand and sign a 1 page procedure for information security.

Step #7 – Don’t automatically buy whatever your IT consultant is selling
By now – you are getting into a security mindset.  Thinking about asset value, attacks and cost-effective security countermeasures like encryption. Download the free risk assessment software and get a feel for your value at risk.  After you’ve done some practical threat analysis of your business risk exposure you will be in an excellent position to talk with your IT consultant. While most companies don’t like to talk about data theft issues, we have found it invaluable to talk to colleagues in your market and get a sense of what they have done and how well the controls perform.

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

The security of open source software

A conversation with a client this morning revolved around software development tool alternatives in an environment of Web Socket.
Why not use Flash on the client and AMF on the server side?, the client asked. I hesitated for a moment and answered – because Adobe is proprietary and closed source and the only developers looking at the code are Adobe employees. If you’ve ever gotten a white screen of death and a cryptic #1707 upload failed message – you know what I mean. Everything else – the security vulnerabilities of Flash, the cost of development, the support costs, all derive from the closed-source proprietary software.

In 2011, there seems to be more awareness that Open Source software is more secure and more reliable. In reality, the most secure systems available today are based on the open source model and peer review. There is absolutely no question that the secret to creating great software that is also secure software is by marshaling as many smart people as possible to the task.

Natalie Walker-Whitlock wrote an excellent article – The security implications of open source software almost 10 years ago and it’s still an excellent read.

Traditionally, software security was equated with secrecy. You lock up your house, your car and your valuables. In the software community, you “lock up” the programming source code as a means of securing it against hackers and competitors.

To the closed source camp, a system can’t be truly secure when its source is open for all to read. This is patently a very bad idea since with good guys and bad guys all looking at a supposedly secure system, disclosing the source discloses software defects and by remedying defects, the software becomes more reliable. More reliable software slows up intruders and reduces the attack surface and, in the event of a data breach, keeps damages due to data loss at a minimum.

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

When defense in depth fails – two deadly sins

Defense in depth is a security mantra,  usually for very good military security and information security reasons.  However – defense in depth may be a very bad idea,  if your fundamental assumptions are wrong or you get blinded by security technology.

The sin of wrong assumptions

In the defense space – we can learn from military history that incorrect security assumptions  carry a high price tag.

The 1973 Yom Kippur war that resulted in a stunning Israel victory but cost 2,800 Israeli lives, and the recent American war in Iraq, that yielded little benefit for the cost of over 30,000 American lives are both illustrations of conceptual mistakes in security strategy.

Neither defense in depth (the Bar Lev line) nor military campaigns for democracy (the Iraq war) were a match for arguable security assumptions  (the  Arabs are deterred by Israeli military superiority (they weren’t), Americans can combat terror with conventional armies (no you cannot).

The sin of techno lust

In the business space  it’s easy to get seduced by sexy security technologies but implementing too many  security technologies will increase operational risk of information security instead of achieving defense in depth.

Why is this so?

Reason 1 : More security elements tends to increase risk instead of improving defenses
Adding more network security elements tends to increase the total system risk, as a result of the interaction between the elements and increased system complexity and resulting  inability to  maintain the systems properly.

For example – companies that attempt to prevent data loss  with more user access lists, enterprise DRM ,  firewalls and proxies experience an inflation of ACLs, end point application software (that needs to be deployed and maintained), firewall rules  that may be outmoded and clients that bypass the proxies.

A company may feel more secure while in practice they are less secure – with dormant accounts, shared passwords, excessive access rights,  orphan accounts, redundant accounts, dormant users, underutilized accounts, abuse of administrator access, backdoor access and … paying more for the privilege.

Reason 2 – Product features do not mitigate threats
Many companies tend to spend a disproportionate amount of their  time evaluating product features instead of performing a business threat analysis and selecting a short list of products that might mitigate the threats.  I first realized this when I paid a sales call on the CSO of a large bank in Israel and his secretary told me that the CSO meets 3-5 vendors/day. It’s nice to be wanted, but 5 years later – the bank still does not have a coherent data security policy, encryption policy nor data loss prevention capability.

Focus on features and vendor profiles  results in installing a product without understanding the return on security investment. After selecting a security product based on marketing and FUD tactics and then implementing the product without understanding how well it reduces value at risk – the customer (not the vendor) pays for ownership of an inappropriate solution in addition to paying for the damage caused by attackers who exploit the unmitigated vulnerabilities.

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

Why security defenses don’t prevent data breaches

Assuming you knew why a data breach will happen, wouldn’t you take your best shot at preventing it?

Consider this:

Your security defenses don’t improve your understanding of the root causes of data breaches, and without understanding the root causes –  your best shot is not good enough.

Why is this so?

First of all – defenses are by definition, not a means of improving our understanding of strategic threats. Think about the Maginot Line in WWI or the Bar-Lev line in 1973. Network and application security products that are used to defend the organization are rather poor at helping us understand and reduce the operational risk of insecure software.

Second of all – it’s hard to keep up.  Security defense products have much longer product development life cycles then the people who develop day zero exploits. The battle is also extremely asymmetric – as it costs millions to develop a good application firewall that can mitigate an attack that was developed at the cost of three man months and a few Ubuntu workstations. Security signatures (even if updated frequently) used by products such as firewalls, IPS and black-box application security are no match for fast moving, application-specific source code vulnerabilities exploited by attackers and contractors.

Remember – that’s your source code, not Microsoft.

Third – threats are evolving rapidly. Current defense in depth strategy is to deploy multiple tools at the network perimeter such as firewalls, intrusion prevention and malicious content filtering. Although content inspection technologies such as DPI and DLP are now available, current focus is primarily on the network, despite the fact that the majority of attacks are on the data – customer data and intellectual property.

The location of the data has become less specific as the notion of trusted systems inside a hard perimeter has practically disappeared with the proliferation of cloud services, Web 2.0 services, SSL VPN and convergence of almost all application transport to HTTP.

Obviously we need a better way of understanding what threats really count for our business. More about that in some up coming posts.

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

Is IT equipped to deal with clear and present danger?

Are the security lights on, but no  one is home at your company?

An April 2010 survey of 80 chief security officers and over 200 members of ASIS International (a trade association for corporate security professionals) basically says that while most large organizations have risk analysis processes – there is no one in charge of risk management.
Question No. 1 – Does your organization have a formalized risk analysis process? … 90 percent of the respondents, said that their organizations have such a formalized risk analysis process.
Question No 2 – Does your organization have an executive with a mandate to manage enterprise risk ? … only about 40 percent of the respondents had an executive with such a mandate.
Erwann Michel-Kerjan, managing director of the Risk Management and Decision Processes Center at Wharton School of Business says:
“That’s hard to believe, given that extreme events and risk management are making headlines almost every other day.”

In order  to understand why large enterprises invest in risk analysis process but not in risk management we need to take a closer look at Western (US and EU for the sake of argument) corporate value systems.

For a manager of a company on the verge of bankruptcy, equity compensation is a one-sided bet with upside only. For example, say the CEO  bets on a bridge loan at usurious terms in order to buy time to close an acquisition deal. If the bet pays off, his equity compensation pays off, but if he loses the bet (and the company goes bankrupt or is sold for a pittance), his personal compensation exposure is zero, but the stockholders, bond holders, customers and business partners will be left holding the bag.  Since it’s a one-sided bet with no downside, executives may also be tempted to adopt borderline business practice in order to proactively optimize their compensation.

Risk analysis provides invaluable input to improve business practice and reduce security breach exposure but you have to execute on the implementation of the security countermeasures and be prepared to hold them up to scrutiny of your peers on a regular basis.  That requires a strong work ethic, transparency and accountability.

Since executives are generally not held personally accountable for security breaches  – it is not surprising at all that most enterprises have  formal risk analysis processes but few firms have managers with  the personal responsibility to execute on security risk management.

Let’s return to our original question – ‘Is IT equipped to deal with clear and present danger?’

We now see that IT and their information security colleagues may indeed have the formal risk analysis processes and even the latest in data security technology countermeasures to reduce the impact of security breaches but they don’t function inside a corporate value system that rewards them for cost-effective security.

And that my friends – is already an ethical question, not a process management nor a compensation question.

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