Modern M2M communication has expanded beyond a one-to-one connection and changed into a system of networks that transmits data to personal appliances using wireless data networks.

M2M networks are much much more than remote meter reading.

The fastest growing M2M segment in Germany, with an average annual growth of 47 percent, will be from consumer electronics with over 5 M2M SIM-cards. The main growth driver is “tracking and tracing”. (Research by E-Plus )

What would happen if the personal appliance was part of the person?

Physiological measurement and stimulation techniques that exploit interfaces to the skin have been of interest for over 80 years, beginning in 1929 with electroencephalography from the scalp.

A new class of electronics based on transparent, flexible 50micron silicon film laminates onto the skin with conformal contact and adhesion based on van der Waals interaction. See: Epidermal Electronics John Rogers et al. Science 2011.

This new class of device is mechanically invisible to the user, is accurate compared to traditional electrodes and has RF connectivity.  The thin 50 micron film serve as temporary support for manual mounting of these systems on the skin in an overall construct that is directly analogous to that of a temporary transfer tattoo, as can be seen in the above picture.

Film mounted devices can provide high-quality signals with information on all phases of the heartbeat, EMG (muscle activity) and EEG (brain activity). Using silicon RF diodes, devices can provide short-range RF transmission at 2Ghz.  Note the antenna on the device.

After mounting it onto the skin, one can wash away the PVA and peel the device back with a pair of tweezers.  When completely removed, the system collapses on itself because of its extreme deformability and skin-like physical properties.

Due to their inherent transparent, unguarded, low cost and mass-deployed nature, epidermal mounted medical devices invite new threats that are not mitigated by current security and wireless technologies.

Skin-mounted devices might also become attack vectors themselves, allowing a malicious attacker to apply a device to the spine, and deliver low-power stimuli to the spinal cord.

How do we secure epidermal electronics devices on people?

Let’s start with some definitions:

• Verification means is the device built/configured for its intended use (for example measuring EMG activity and communicating the data to NFC (near field communications) device.
• Validation means the ability to assess the security state of the device, whether or not it has been compromised.
• RIMs (Reference Integrity Measurements) enable vendors/healthcare providers define the desired target configurations of devices, for example, is it configured for RF communications

There are 3 key threats when it comes to epidermal electronics:

1. Physical attacks: Reflashing before application to the skin in order.
2. Compromise of credentials: brute force attacks as well as malicious cloning of credentials.
3. Protocol attacks against the device: MITM on first network access, DoS, remote reprogramming

What are the security countermeasures against these threats?  We can consider a traditional IT security model and a trusted computing model.

Traditional IT security model?

Very large numbers of low-cost, distributed devices renders the central IT/firewall based model inappropriate. Even you were to consider a firewall on an epidermal electronics device, how would you enforce manufacturing devices with firewalls and then managing the policies? What kind of policy would you want to manage?

Trusted computing model?

A “trusted computing model”  may be considered as an alternative security countermeasure to access control and policy management.

An entity can be “trusted” if it predictably and observably behaves in the expected manner for its intended use. But what does “intended use” mean in the case of epidermal electronics that are used for EKG, EEG and EMG measurements on people?

Can the traditional, layered, trusted computing models used in the telecommunications world be used to effectively secure cheap, low-cost, epidermal electronics devices?

In an M2M trusted computing model there are 3 methods:  autonomous validation, remote validation and semi-autonomous validation. We will examine each and try and determine how effective each model is as a security countermeasure for the key threats of epidermal electronics.See: “Security and Trust for M2M Communications” - Inhyok Cha, Yogendra Shah, Andreas U. Schmidt, Andreas Leicher, Mike Meyerstein

Autonomous validation

This is essentially the trust model used for smart cards, where the result of local verification is true or false.

Autonomous validation does not depend on the patient herself or the healthcare provider. Local verification is assumed to have occurred before the skin-mounted device attempts communication or performs a measurement operation.

Autonomous validation makes 3 fundamental assumptions – all 3 are wrong in the case of epidermal electronics:

1. The local verification process is assumed to be perfectly secure since the results are not shared with anyone else, neither the patient nor the healthcare provider.
2. We assume that the device itself is completely trusted in order to enforce security policies.
3. We assume that a device failing self-verification cannot deviate from its “intended use”.

Device-based security can be broken and cheap autonomous skin-mounted devices can be manipulated – probably much easier than cell-phones since for now at least, they are much simpler. Wait until 2015 when we have dual core processors on a film.

In addition, autonomous validation does not mitigate partial compromise attacks (for example – the device continues to measure EMG activity but also delivers mild shocks to the spine).

Remote validation

Remote validation has connectivity, scalability and availability issues. It is a probably a very bad idea to rely on network availability in order to remotely validate a skin-mounted device.

In addition to the network and server infrastructure needed to support remote validation, there would also be a huge database of RIMs, to enable vendors and healthcare providers define the target configurations of devices.

Run-time verification is meaningless if it is not directly followed by validation, which requires frequent handshaking with central service providers.

Remote validation of personally-mounted devices compromises privacy since the configuration may be virtually unique for a particular person.

Discrimination by vendors becomes possible, as manipulation and control of the RIM databases could lock out other applications/vendors.

Semi-Autonomous Validation

The device verifies itself locally and signals the results to the healthcare provider who can decide if he needs to notify the user/patient if the device has been compromised or does not match the intended use.

The signaling process itself needs to ensure authentication, integrity, and confidentiality.

Semi-autonomous validation divides verification and enforcement between the device and the healthcare provider.

RIM certificates are a key part of semi-autonomous validation and would be signed by a trusted third party/CA.

Semi-autonomous validation also allows for more granular delegation of control to the device itself or the healthcare provider – depending on the functionality.

Summary

Epidermal electronics devices are probably going to play a big part in the future of healthcare for monitoring vital signs in a simple, cheap and non-invasive way.  These are medical devices, used today primarily for measuring vital signs that are directly mounted on the skin and not a Windows PC or Android smart phone that can be rebooted if there is a problem.

As their computing capabilities develop, current trusted computing/security models will be inadequate for epidermal electronics devices and attention needs to be devoted as soon as possible in order to build a security (probably semi-autonomous) model that will mitigate threats by malicious attackers.

 References

1. Security and Trust for M2M Communications - Inhyok Cha, Yogendra Shah, Andreas U. Schmidt, Andreas Leicher, Mike Meyerstein
2. Epidermal Electronics John Rogers et al. Science 2011.

Online interactions with our HMO

We have online interactions with our healthcare organizations; accessing a Web portal for medical history, scheduling visits etc. Our PHI (protected healthcare information) is hopefully well-secured by our healthcare provider under government regulation (HIPAA in the US, and the Data Protection Directive in the EU). Albeit in the name of privacy, healthcare providers often take security to absurd extremes, witness the following anecdote:

I tried using online medical services with my provider in Hawaii but they could not respond due to my not being in Hawaii. What good is online diagnostic services when the patient is not in his/her home state?

Well now, I thought, that’s why Al Gore invented the Internet so that we could access healthcare services anywhere, anytime. Guess not. With our healthcare provider, we interact with the IT department. Bummer. On Facebook we interact with our friends. Compassion.

A healthcare provider’s business model requires them to protect your health information from disclosure. This is generally interpreted as doing as little as possible to help you be healthy. Social media business models require them to maximize distribution of your content. This means that your privacy is up to you and the people you connect with.

It seems obvious to me, that privacy regulation cannot work in social media because the connectivity is so high. There is no central data center where you can install an IPS and DLP systems and implement all of HIPAA CFR 45 Appendix A administrative, physical and technical safeguards. In that case, let’s get back to basics. We agree that privacy in our healthcare interactions is critical.

What is privacy?

pri·va·cy/ˈprīvəsē/

1. The state or condition of being free from being observed or disturbed by other people.
2. The state of being free from public attention

Healthcare privacy by design

Just like you are alone with your doctor in his office,we can build a private social network where the topology of the network guarantees privacy. We describe a star topology where one doctor interacting with many patients. We guarantee online privacy in our star topology network with 3 simple principles;

1. Each doctor has his own private network of patients.
2. In the private network, patients do not interact with other patients (interact as in friending, messaging etc.). We can expand the definition a bit by allowing a patient to friend another person in a caregiver role, but this is the only exception to the rule.
3. A doctors private network does not overlap with other doctor networks, although doctors connect with each other for referrals.

This is a private network for healthcare by design.

What makes it a private social network, is the use of the same social apps we use in social media like Twitter and Facebook: friending, short messaging, status updates, groups, content sharing and commenting/liking.

A doctor uses a private social network for healthcare with the same 3 basic primitives of public social networking: Connect (or friend), Follow and Share.

One of the things that excites me the most about private social networks for healthcare is the potential to make the information technology go away and put the focus back on the patient-physican interaction and quality of clinical care.

• Doctors save time in interviews because patients can record events and experiences before they come in to the office.
• Data is more accurate since patients can record critical events like falls and BP drops, in proximity to the event itself.
• Better data makes physician decisions easier and faster.
• Better data is good for health and easier and faster is good for business.

What a beautiful business model – compassion, care and great business!

When you have multiple Dropbox clients configured, your files will be instantly synchronized between all your devices when they come online. I use it daily to exchange files between my Android phone, Android tablet and Ubuntu desktop. Any change performed in the monitored folder is immediately synchronized with the other devices. My colleague Sharon, who has an iPad3 and a iMac, is synchronized with me and we can quickly exchange files regarding cases we are working on together especially leading up to our weekly review meeting.

Dropbox – public by design

Dropbox is easy but is it private?  The short answer is that you should not store PHI (protected health information on Dropbox – since they share data with third party applications and service providers, but the real reason is you should not use Dropbox for sharing healthcare information with patients is simply that it is not private by design.  Everyone who shares a folder in your dropbox sees all the files in the dropbox.

From the Dropbox Privacy policy:

We may collect and store the following information when running the Dropbox Service:

Information You Provide.   When you register an account, we collect some personal information, such as your name, phone number, credit card or other billing information, email address and home and business postal addresses.

Personal Information.   In the course of using the Service, we may collect personal information that can be used to contact or identify you (“Personal Information”). Personal Information is or may be used: (i) to provide and improve our Service, (ii) to administer your use of the Service, (iii) to better understand your needs and interests, (iv) to personalize and improve your experience, and (v) to provide or offer software updates and product announcements.

Service Providers, Business Partners and Others.   We may use certain trusted third party companies and individuals to help us provide, analyze, and improve the Service (including but not limited to data storage, maintenance services, database management, web analytics, payment processing, and improvement of the Service’s features). These third parties may have access to your information only for purposes of performing these tasks on our behalf and under obligations similar to those in this Privacy Policy.

Third-Party Applications.   We may share your information with a third party application with your consent,

Data retention. We may retain and use your information as necessary to comply with our legal obligations, resolve disputes, and enforce our agreements.

Privacy of healthcare information by design

If you want to have complete control and privacy of data that you share with patients, you need a controlled, private social network for healthcare that ensures no overlap between patients and no overlap between physician networks.  This is privacy by design.

The roles of trust, security and privacy in healthcare.  If President Obama had told his psychiatrist he was gay, you can bet that it would be on Facebook in 5′. So much for privacy.

pri·va·cy/ˈprīvəsē/

Noun:

The state or condition of being free from being observed or disturbed by other people.

The state of being free from public attention

When it comes to healthcare information, there have always been two circles of trust – the trust relationship with your physician and the trust that you place in your healthcare provider/insurance company/government health service.

With social networks like Facebook, a third circle of trust has been created: the circle of trust between you and your friends in the social network.

Patient-doctor privacy

When we share our medical situation with our doctor, we assume we can trust her to keep it private in order to help us get well. Otherwise – we might never share information regarding thoses pains in in the right side over our abdomen, and discover after an ultrasound has been done, that our fatty liver is closely related to imbibing too many pints of beer and vodka chasers with the mates after work – when you have been telling the missus that you are working late at the office.

Healthcare provider – patient privacy

When we share medical information with our healthcare provider, we trust their information security as being strong enough to protect our medical information from a data breach. Certainly – as consumers of healthcare services, it’s impossible for us to audit the effectiveness of their security portfolio.

With our healthcare provider, revealing personal information depends on how much we trust them and that trust depends on how good a job they do on information security, and how effectively they implemented the right management, technical and physical safeguards.

If you’re not sure about the privacy, trust and security triangle, just consider Swiss banks.

Millions of people have online healthcare interactions – asking doctors questions onlines, sharing experiences in forums, interacting with doctors using social media tools like blogs and groups and of course – asking Dr. Google.

Privacy among friends

When we share medical information with our friends on Facebook/Google+ or Twitter we trust them to keep it private within our own personal parameters of vulnerability analysis.

Note that there is feeling secure (but not being secure – chatting about your career in crime on Facebook) and being secure while not feeling secure (not wanting to use your credit card online – face it, with over 300 million credit cards breached in the past 5 years, chances are, your credit card is out there and it doesn’t seem to make a difference now, does it?).

Trust between 2 people interacting (whether its face-to-face or on Facebook) is key to sharing sensitive information, since it mitigates or eliminates the damage of unexpected disclosure.

Let’s illustrate the notion of personal trust as a security countermeasure for unexpected disclosure with a story:

Larry interacts with his lawyer Sarah regularly, once a week or more. It’s a professional relationship, and over time, Larry and Sarah gain each others trust, and in addition to contracts and commercial terms and conditions, the conversations encompass children, career and life. Larry knows Sarah is divorced and is empathetic to the challenges of being a full-time mother and corporate lawyer. Come end of year, Larry sends Sarah a box of chocolate wishing her a successful and prosperous New Year. Sarah’s 14 year old daughter, who is pushing her to start dating again, sees the gift package and draws conclusions that Mom has a new beau. Sarah now has to go into damage control mode with a teenage daughter. It may take Larry months (if ever…) to regain the trust of his colleague. This is literally the damage of unexpected disclosure of private information.

Unlike a healthcare provider, on Facebook we only interact with our friends.

We have digital interactions with our healthcare provider, accessing a Web portal for medical history, scheduling visits and lab tests online etc. These are interactions unrelated to the personal relationship with our physician. The data in these interactions is regulated by governments and secured by healthcare provider information security organizations.

Your healthcare provider’s business model requires them to protect your health information from disclosure.

In our digital interactions on Facebook or Twitter,  there is no organizational element to the security, trust and privacy equation only the personal element. This is because your Gmail, tweets and Facebook conversations are the content that drives Google, Twitter and Facebook advertising revenues.

Social media business models require them to distribute as much of your content as possible.

So, is there a reasonable solution to ensure private healthcare interactions on social networks?

The answer,  I believe, lies in getting back to the dictionary definition of privacy, and creating a private social network for healthcare that enables you, your doctor and family to “be free from being observed or disturbed by other people”.

Here are 5 practical things I would recommend to any healthcare organization CIO:

1. Do not rely on fixed controls

Any information security professional will tell you that security countermeasures are comprised of people, processes and technology.  The only problem is that good security depends on stable people, processes and technology. A stable organization undergoing rapid and violent change is an oxymoron.  Visualize your company has ISO 27001 certification but the stock drops by 90% because of an options back-dating scandal at the top, the company fires 900 employees and all of a sudden, the fixed controls are not as effective as you thought they were.  Think about the Maginot Line in WWII.

2. Use common sense when it comes to people

People countermeasures should be a mix of common-sense, background checks (at a depth proportional to job exposure to sensitive assets), and deterrence.  Andy Grove once said

“Despite modern management theory regarding openness – a little fear in the workplace is not a bad thing”.

When a lot of employees are RIF‘d – there is a lot of anger and people who don’t identify with their employer; the security awareness training vaporizes and fear and revenge take over. Some of the security people will be the first to go, replaced by contractors who may not care one way or the other or worse – be tempted by opportunities offered by the chaos. In  a large complex healthcare organization, large scale security awareness training is probably a hopeless waste of resources considering the increasing number of options that people have (Facebook, smartphones..) to do stuff that causes damage to the business.Security awareness will lose every time it comes up against an iPad or Facebook.

Why is  common sense a good alternative to awareness training?

Common sense  is easy to understand and enforce if you keep it down to 4 or 5 rules:  maintain strong passwords, don’t visit porn sites, don’t blog about the business, don’t insert a disk on key from anyone and maintain your notebook computer like you guard your cash.

3. Spend some money on securing your software applications instead of on security theater

It’s a given that business processes need to be implemented in a way that ensures confidentiality, integrity and availability of customer data.  A simplistic example is a process that allows a customer service representative to  read off a full credit card number to a customer. That’s a vulnerability that can be exploited by an attacker.  But – that’s a trivial example – while you’re busy managing processes and using security theater code words – the attackers are attacking your software and stealing your data.

4. Question your defenses 

Technology countermeasures are not a panacea – and periodically you have to step back and take a look at your security portfolio both from a cost and effectiveness perspective.  You probably reply on a defense in depth strategy but end up with multiple, sometimes competing and often ineffective tools at different layers – workstation, servers and network perimeter.

Although defense-depth is a sound strategy – here are some of the fault lines that may develop over time:

5. Invest in smart people instead  (instead of investing in business alignment)

Business alignment is one of those soft skill activities that keep people in meetings instead of mitigating healthcare  vulnerabilities – which requires hard professional skills and high levels of professional security competence. It’s a fact of life that problem solvers hate meetings and rightly so – you should invest in smart people and go light on the business alignment since it will never stop the next data breach of your patients’ data.

Claudiu Popa, president and chief security officer of data security vendor Informatica Corp. told  Robert Westervelt in an interview  on searchsecurity.com that:

…once an organization reaches the right level of maturity, security measures will not only save time and money, but also contribute to improved credibility and efficiency.

This is nonsense – security is a cost  and it rarely contributes to efficiency of a business (unless the business can leverage information security as part of it’s marketing messages) and as  for an organization firing 30% of it’s workforce over night – words like maturity, credibility and efficiency go out the door with the employees.

At that point –  highly competent and experienced security professionals who are thinking clearly and calmly are your best security countermeasure.

But – if you are small to mid-size hospital or nursing home or medical device vendor without large budgets for security compliance, the natural question you ask is “How can I do this for as little money as possible?”

You can do some research online and then hire a HIPAA security and compliance consultant who will walk you through the security safeguards in CFR 45 Appendix A and help you implement as many items as possible.  This seems like a reasonable approach, but the more safeguards you implement, the more money you spend and moreover, you do not necessarily know if your security has improved -since you have not examined your value at risk – i.e how much money it will cost you if you have a data security breach.

If you read CFR 45 Appendix A carefully, you will note that the standard wants you to do a top-down risk analysis, risk management and periodic information security activity review.

The best way to do that top down risk analysis is to build probable threat scenarios – considering what could go wrong – employees stealing a hard disk from a nursing station in an ICU where a celebrity is recuperating for the information or a hacker sniffing the hospital wired LAN for PHI.

Threat scenarios as an alternative to compliance control policies

When we perform a software security assessment of a medical device or healthcare system, we think in terms of “threat scenarios” or “attack scenarios”, and the result of that thinking manifests itself in planning, penetration testing, security countermeasures, and follow-up for compliance. The threat scenarios are not “one size fits all”.  The threat scenarios for an AIDS testing lab using medical devices that automatically scan and analyze blood samples, or an Army hospital using a networked brain scanning device to diagnose soldiers with head injuries, or an implanted cardiac device with mobile connectivity are all totally different.

We evaluate the medical device or healthcare product from an attacker point of view, then from the management team point of view, and then recommend specific cost-effective, security countermeasures to mitigate the damage from the most likely attacks.

1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
2. Executives related well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.
3. Threat scenarios are a common language between IT, security operations teams and the business line managers

This last benefit is extremely important in your healthcare organization, since business delegates security to IT and IT delegates security to the security operations teams.

As I wrote in a previous essay “The valley of death between IT and security“, there is a fundamental disconnect between IT operations (built on maintaining predictable business processes) and security operations (built on mitigating vulnerabilities).

Business executives delegate information systems to IT and information security to security people on the tacit assumption that they are the experts in information systems and security.  This is a necessary but not sufficient condition.

In the current environment of rapidly evolving types of attacks (hacktivisim, nation-state attacks, credit card attacks mounted by organized crime, script kiddies, competitors and malicious insiders and more…), it is essential that IT and security communicate effectively regarding the types of attacks that their organization may face and what is the potential business impact.

If you have any doubt about the importance of IT and security talking to each other, consider that leading up to 9/11, the CIA  had intelligence on Al Qaeda terrorists and the FBI investigated people taking flying lessons, but no one asked the question why Arabs were learning to fly planes but not land them.

With this fundamental disconnect between 2 key maintainers of information protection, it is no wonder that organizations are having difficulty effectively protecting their assets – whether Web site availability for an online business, PHI for a healthcare organization or intellectual property for an advanced technology firm.

IT and security  need a common language to execute their mission, and I submit that building the security portfolio around most likely threat scenarios from an attacker perspective is the best way to cross that valley of death.

There seems to be a tacit assumption with many executives that regulatory compliance is already a common language of security for an organization.  Compliance is a good thing as it drives organizations to take action on vulnerabilities but compliance checklists like PCI DSS 2.0, the HIPAA security rule, NIST 800 etc, are a dangerous replacement for thinking through the most likely threats to your business.  I have written about insecurity by compliance here and here.

Let me illustrate why compliance control policies are not the common language we need by taking an example from another compliance area – credit cards.

PCI DSS 2.0 has an obsessive preoccupation with anti-virus.  It does not matter if you have a 16 quad-core Linux database server that is not attached the Internet with no removable device nor Windows connectivity. PCI DSS 2.0 wants you to install ClamAV and open the server up to the Internet for the daily anti-virus signature updates. This is an example of a compliance control policy that is not rooted in a probable threat scenario that creates additional vulnerabilities for the business.

Now, consider some deeper ramifications of compliance control policy-based security.

When a  QSA or HIPAA auditor records an encounter with a customer, he records the planning, penetration testing, controls, and follow-up, not under a threat scenario, but under a control item (like access control). The next auditor that reviews the  compliance posture of the business  needs to read about the planning, testing, controls, and follow-up and then reverse-engineer the process to arrive at which threats are exploiting which vulnerabilities.

Other actors such as government agencies (DHS for example) and security researchers go through the same process. They all have their own methods of churning through the planning, test results, controls, and follow-up, to reverse-engineer the data in order to arrive at which threats are exploiting which vulnerabilities.

This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

• Lack of overview of the the security threats and vulnerabilities that really count
• No sufficient connection to best practice security controls, no indication on which controls to follow or which have been followed
• No connection between controls and security events, except circumstantial
• No ability to detect and warn for negative interactions between countermeasures (for example – configuring a firewall that blocks Internet access but also blocks operating system updates and enables malicious insiders or outsiders to back-door into the systems from inside the network and compromise  firewalled services).
• No archiving or demoting of less important and solved threat scenarios (since the data models are control based)
• Lack of overview of security status of a particular business, only a series of historical observations disclosed or not disclosed.  Is Bank of America getting better at data security or worse?
• An excess of event data that cannot possibly be read by the security and risk analyst at every encounter
• Confidentiality and privacy borders are hard to define since the border definitions are networks, systems and applications not confidentiality and privacy.

Using value at risk to figure out how much a breach will really cost you

Your threat scenarios must consider asset (your patient information, systems, management attention, reputation) values, vulnerabilities, threats and possible security countermeasures. Threat analysis as a methodology does not look for ROI or ROSI (there is no ROI for security anyhow) but considers the best and cheapest way to reduce asset value at risk.

And – as we opened the article – the question is  ”How can I do this for as little money as possible?”

As Brian W. Kernighan and Rob Pike wrote in “The Practice of Programming“

As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.

In programming, it is faster to examine the contents of a couple of variables than to single-step through entire sections of code.

Collecting security logs is key to information security management not only for understanding what and why an event happened but also in order  to  prove regulatory compliance with regulations such as the HIPAA security rule. The business requirements are that   security logs  should be both relevant and effective.

1. Relevant content of audit controls:  For example, providing a  detailed trace of an application whenever it elevates privilege in order to execute a system level function.
2. Effective audit reduction and report generation:  Given the large amount of data that must be analyzed in security  logs, its crucial that critical events are separated from normal traffic and that concise reports can be produced in real-time to help understand  what happened, why it happened and how it was mediated and how to mitigate similar risks in the future.

In security log analysis, it is faster and definitely more effective for a security analyst to examine the contents of a few real time events than to process gigabytes or terabytes of security logs (the equivalent of stepping through or placing watch points in sections of of a sub-modules with  hundreds or thousands of lines of code.

When you have to analyze security logs, it is easy to get lost in details of complicated data and flows of events and find yourself drifting off into all kinds of directions even as the bells go on in the back of your mind that you are chasing ghosts in a futile and time-consuming exercise of investigation and security event debugging.

In order to understand this better, consider another analogy, this time from the world of search engines.

Precision and recall are key to effective security log analysis and effective software debugging.

In pattern recognition and information retrieval, precision is the fraction of retrieved instances that are relevant, while recall is the fraction of relevant instances that are retrieved. Both precision and recall are therefore based on an understanding and measure of relevance. When a program for recognizing the dogs in a scene correctly identifies four of the nine dogs but mistakes three cats for dogs, its precision is 4/7 while its recall is 4/9. When a search engine returns 30 pages only 20 of which were relevant while failing to return 40 additional relevant pages, its precision is 20/30 = 2/3 while its recall is 20/60 = 1/3. See Precision and recall in the Wikipedia.

In other words – it doesn’t really matter if you have to analyze a program with 100,000 lines of code or a log file with a terabyte of data – if you have good precision and good recall.

The problem is however, that the more data you have, the more difficult it is to achieve high precision and recall and that is why real-time events (or  debugging statements) are more effective in day-to-day security operations.

In order to determine how encryption fits into server data protection, consider 4 encryption components on the server side: passwords, tables, partitions and  inter-tier socket communications.

In these 4 components of a application / database server encryption policy, note that some countermeasures are required (for example one-way hashes of passwords, while other such as encrypting specify table columns may or may not be relevant to a particular application).

1. Encrypted password storage

You must encrypt passwords. It’s surprising to me how many Web sites don’t bother encrypting user passwords – See cases Universal Music Portugal where e-mail addresses and clear-text passwords are dumped on Internet.

What is more surprising is the confusion between encryption and hashing.

Don’t use AES for encrypting passwords in your MySQL or Oracle or MS SQL database.  You’ll end up storing the AES key somewhere in the code and an attacker or malicious insider can read the key by opening up one of your application DLLs in Notepad++ and read that key in a jiffy and breach your entire MySQL database with a single SELECT statement.

Database user passwords should be stored as MD5 hashes, so that a user  (such as a DBA) who has been granted SELECT access to the table (typically called ‘users’)  cannot determine the actual password. Make sure that different instances have different salts and include some additional information in the hash.

If you use MD5 encryption for client authentication, make sure that  the client hashes the password with MD5 before sending the data on the network.

2. Encrypt specific database table columns

The PostgreSQL 9.1 pgcrypto module allows certain fields to be stored encrypted. This is especially useful if some of the data is sensitive for example in the case of ePHI where the Web application needs to comply with the CFR 45 Appendix A Security rule. The client software provides the decryption key and the data is decrypted on the server and then sent to the client.  In most cases the client (a database driver in an MVC application such as Ruby on Rails or CakePHP or ASP.NET MVC is also a server side resource and often lives on the same physical server as the database server. This is not a bad thing.

3. Encrypt entire data partitions

Encrypting entire data partitions has its place.

On Linux, encryption can be layered on top of a file system using a ”loopback device”. This allows an entire file system partition to be encrypted on disk, and decrypted by the operating system. Many operating systems support this functionality, including Windows.

Encrypting entire partitions is a security countermeasure for physical attacks, where the entire computer is stolen. Research we did in 2007 indicated that almost 50% of large volume data breaches employed a physical attack vector (stealing a notebook at a hotel checkin desk, hijacking a truck transporting backup tapes to Iron Mountain and smash and grab jobs where thieves know the rent-a-cop walkaround schedule and break in and steal desktop computers.

On the other hand, once the volume is mounted,  the data is visible.

4. Encrypt socket communications between server tiers

SSL has it’s place, although SSL is not a silver bullet countermeasure for Microsoft Windows vulnerabilities and mobile medical devices vulnerabilities as I wrote here, here and here.

SSL connections encrypt all data sent across the network: the password, the queries, and the data returned. In database client-server connections,  relational database systems such as PostgreSQL allow administrators to specify which hosts can use non-encrypted connections (host) and which require SSL-encrypted connections (hostssl). Also, clients can specify that they connect to servers only via SSL. Stunnel or SSH can also be used to encrypt transmissions.

A friend who is a commercial pilot had his bag swiped literally behind his back while waiting on line to check-in to a 4 star Paris hotel. The hotel security cameras show the thief moving quickly behind his back, quietly taking the bag and calmly walking off.

Is your user password 123456?

The Wharton School at UPenn recently posted an article – is your password 123456?

As the article notes – “Hack attacks have recently hit government agencies, news sites and retailers ranging from the U.S. Justice Department and Gawker to Sony and Lockheed Martin, as hackers become more sophisticated in their ability to steal customers’ identities and personal information.”

But, you don’t need sophisticated hack attacks to know that many people use simple minded passwords like 123456 and thieves use simple techniques like grab and run.

So – why don’t we all use strong passwords?

Every Web site and business application you use has a  different algorithm and password policy.  For users, who need to maintain strong passwords using 25 different policies on 25 different systems and web sites, it’s impossible to maintain a strong password policy without making some compromises.

The biggest vulnerability is using your corporate password on an online porn site.  Since adult sites are routinely subject to attack and cheesier, more marginal adult sites – (mind you we’re not talking Penthouse.com or Playboy.com perish the thought) are frequently unwitting malware distribution platforms.

Here are 5 rules for safe password management :

1. Use technical aids to manage your passwords.  Consider using Keepass password management
2. Match password  strength to asset value. In other words – use a complex combination of letters and numbers for online banking and a simple easy to remember password for Superball news.
3. Don’t reuse.   Don’ use the same strong password on more than one sites.
4. Make passwords easy to remember but hard to guess.  Adopt mnemonics – like 4Tshun KukZ that you can remember
5. Maintain physical security of your passwords.  Treat your passwords like you treat the cash in your wallet.  If you have to write passwords down, put them on a piece of paper in your wallet and treat that piece of paper like a $100 bill,  make sure you don’t lose that wallet.