Tag Archives: Cloud computing

Securing Web servers with SSL

I’ve been recently writing about why Microsoft Windows and the Microsoft monoculture in general  is a bad idea for medical device vendors – see my essays on Windows vulnerabilities and medical devices here, here and here.

It is now time to slaughter one more sacred cow: SSL.

One of the most prevalent misconceptions with vendors in the medical device and healthcare space regards the role of SSL and TLS in protecting patient information.  When faced with a requirement by a government or hospital customer for compliance to one of the US privacy and security standards, a vendor usually reacts with the CEO asking his CTO to look into “solutions”. The CTO’s answer usually goes  like this:

I did some research. Apparently to be FIPS  (or HIPAA, or …) compliant we should use TLS and not SSL. I think that configuring the browser to be FIPS  (or HIPAA, or …) compliant may take a little work.

Action items are given out to the technical team, they usually look like this:

Joe – You establish a secure web site

Jack – Make sure all the addresses on the workstation point to https instead of http

Jack and Joanne – Compile a new version of the Servers and workstation to work properly on the new site.

Jack and Jill – Do what ever needs to be done so that the web services work on the new site.

That’s all – No other changes need to be done to the application.

Oooh.  I just love that last sentence – “No other changes need to be done to the application”.  What about patching Web servers and the Windows operating systems? What about application software vulnerabilities?  What about message queue vulnerabilities ? What about trusted insiders, contractors and business partners who have access to the application software?

There are multiple attack vectors from the perspective of FIPS and HIPAA compliance and PHI data security.  The following schematic gives you an idea of how an attacker can steal PHI, figure using any combination of no less than 15 attack vectors to abuse and steal PHI:

HIPAA security in the cloud

There are potential data security vulnerabilities in the client layer, transmission layer, platform layer (Operating system) and cloud services (Amazon AWS for example).

So where does SSL fit in? Well, we know that the vulnerabilities for a PHI data breach can not only happen inside any layer but in particular there are vulnerabilities in the system interfaces between layers. That means between server layers and client-server interfaces.  SSL  Quoting from the Apache Tomcat 6.0 SSL Configuration HOW-TO:

SSL, or Secure Socket Layer, is a technology which allows web browsers and web servers to communicate over a secured connection. This means that the data being sent is encrypted by one side, transmitted, then decrypted by the other side before processing. This is a two-way process, meaning that both the server AND the browser encrypt all traffic before sending out data.

Another important aspect of the SSL protocol is Authentication. This means that during your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a “Certificate”, as proof the site is who and what it claims to be. In certain cases, the server may also request a Certificate from your web browser, asking for proof that you are who you claim to be. This is known as “Client Authentication,” although in practice this is used more for business-to-business (B2B) transactions than with individual users. Most SSL-enabled web servers do not request Client Authentication.

In plain English, SSL is good for protecting credentials transmitted between the browser and web server during the login process from eavesdropping attacks.  SSL may still be vulnerable to man in the middle attacks by malware that piggybacks on the plain text browser requests and responses before they are encrypted. Similarly, SSL may be vulnerable to cross-site scripting attacks like the Paypal XSS vulnerability discovered in 2008 that would allow hackers to carry out attacks, add their own content to the site and steal credentials from users.

SSL is a key component in a secure login process, but as a security countermeasure for application software vulnerabilities, endpoint vulnerabilities, removable devices, mobile devices and data security attacks by employees,  servers and endpoints, it is worse than worthless because it sucks the medical device/healthcare vendor into a false feeling of security.

SSL does NOT make a medical device/healthcare Website secure. The SSL lock symbol in the  browser navigation window just means that data in motion between a browser client and Web server is encrypted.   If you can attack the endpoint or the server – the data is not protected. Quoting Gene Spafford ( I think this quote has been used for years but it’s still a good one)

“Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench.”
Gene Spafford Ph.D. Purdue, Professor of Computer Sciences and Director of CERIAS

This is all fine and dandy, but  recall our conversation from the CTO giving action items to his team to “establish a secure web site” as if it was point and click on a Microsoft Office file. The team may discover that even though SSL is not a very good data security countermeasure (albeit required by FIPS and HIPAA), it may not be that easy to implement, let alone implement well.

It’s no wonder that so many web servers are misconfigured by the clueless being led by other clueless people who never read the original documentation and were all feeding off google searches for tutorials. Yikes!

Most people don’t bother reading the software manuals and google for advice looking for things like “Tomcat SSL configuration tutorial“.  Jack, and Jill and Joanne in our example above, may discover themselves wandering in an  abundance of incorrect,incomplete and misleading information in cyberspace, which is mixture of experts who assume everyone  knows how to setup secure AJP forwarding and Tomcat security constraints and a preponderance of newbies who know nothing (or a little bit, which is worse than nothing).

Working with a client in the clinical trial space, I realized that the first and perhaps biggest problem is a lack of decent documentation, so I wrote SSL and Certificate HOW TO – Apache 2.2 and Tomcat 6, Ubuntu which I hope will be my modest contribution (along with this blog) to dispelling some of the confusion and misconceptions and helping medical device and healthcare vendors implement secure Web applications. No promises – but at least I try to do my bit for the community.

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

The connection between application performance and security in the cloud

I met with Avner Algom last week in his office in Herzliya. Avner is the director of the Israeli Cloud and Grid Technology Consortium – IGT – The IGT is a non-profit organization of leading industry companies, vendors, ISVs, customers, VCs and academia, focused on knowledge sharing and networking for developing Cloud computing/SaaS, Virtualization and SmartGrid solutions. It is open, independent and vendor-neutral.

It is significant that discussions of cloud security and performance focus almost exclusively on infrastructure issues such as virtualization or procedural issues such as infrastructure compliance with various security standards and frameworks.

I remarked to Avner in the course of our chat, that there is a close correlation between performance and security issues for Web applications running in the cloud.  Avner  asked me how I came to that conclusion.

Here is why cloud performance and cloud security have common issues.

Virtually all applications deployed in the cloud are either Web-based applications or smartphone apps for Android or IOS that use http/https as their application transport.

The current rich Web 2.0 application model is broken and it has nothing to do with the  serious and fundamental issues with Microsoft monoculture, Windows operating systems vulnerabilities and Internet Explorer non-compliance with IETF  standards.

It will not help if you use Ruby on Rails or CakePHP or Zend Framework either. The debate between the Ruby on Rails, ASP.NET and PHP camps is mildly interesting but irrelevant from a cloud security and performance perspective.

A deeper look at Web applications reveals that the current rich Web 2.0 application development and execution model suffers from a broken architecture that cannot be fixed by tweaking languages.

Further examination shows that data typing, message passing, redundant code, data and multiple tier issues that are security vulnerabilities for Web applications in the cloud are also root causes of application performance issues and latency that result in a poor user experience and high cost of operation for the application operator. Note that in a utility model where you pay for CPU cycles,  you pay more for inefficient applications. That is the dark side of the externally vivacious cloud service model.

The attached presentation examines some of the root causes of the currently broken Web 2.0 application development and execution model and shows that the same security vulnerabilities born out of Web 2.0 client/server architecture result in 10x poorer performance than a traditional client-server model based on stateful, TCP unicast socket communications.

See Web application security in the cloud

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

Why your IT vendor doesn’t want you to do a risk analysis

Did you ever have a feeling that your IT integrator was treating you like a couple of guys selling you a Persian rug?  “Take it now – it’s so beautfiful, just perfect for your living room, a steal  for only $10,000 and it’s on sale” and when you ask if it will last, they tell you “Why do you want it to last? Enjoy, use it in good health, wear it out quickly and come back to the store so that we can sell you Persian Rug 2012”.

I had a meeting with a long-time client today – I’ve developed some systems for them in the FDA regulatory and clinical trial management space. We met for lunch to discuss a new project which involved an extension to an existing multi-center study.

The question of disaster recovery planning and offsite backup came up and  they asked me what I thought about backing up their clinical trial data together with their office file backups taken by their outsourcing IT provider.

I said this is a very bad idea because while their IT contractor specializes in providing Microsoft Windows/Office support for small businesses, they just don’t have the know-how or security expertise for HIPAA compliant data storage.

In general, small business IT integrators are  behind the curve on data security, compliance, disaster recovery and application software security. Their job is to keep Microsoft SBS running smoothly and install anti-virus software, not mitigate data security and HIPAA compliance attacks. The typical SMB integrator mindset is dominated by the Microsoft monoculture, and I would not expect them to be able to analyze data security threats correctly.

Whenever I go somewhere – I’m always looking at things with a security perspective – open doors, windows – things that could be easily lifted. Who might be a threat. Storing clinical data with a bunch of Microsoft Office files is just too big a risk to take. The CEO accepted my recommendation to encrypt data on a secure, hardened virtual server instance in the cloud and monitor potential exposure to new emerging threats as their application and project portfolio evolves.

After lunch and getting back into the office, I realized that Risk analysis is a threat to IT vendors.

Not every security countermeasure is effective or even relevant for your company. This is definitely a threat to an IT vendor salesperson who must make quota.

I am a big proponent of putting vendor suggestions aside and taking some time to perform a business threat analysis (shameless plug for our business threat analysis services,  download our free white paper and learn more about Business Threat Modeling and security management). In a business threat  analysis you ignore technology for a week or 2 and systematically collect assets, threats, vulnerabilities …and THEN examine the cost-effective security countermeasures.

Your vendor wants to sell you a fancy $20,000 application security/database firewall, but it may turn out that your top vulnerability is from 10 contract field service engineers who shlep your company’s source code on their notebook computers. You can mitigate the risk of a stolen notebook by installing a simple security countermeasure – Free open-source disk encryption software for Windows Vista/XP, Mac OS X, and Linux.

Information security vendors often promote their backup/data loss prevention/data retention/application security products using a compliance boogeyman.

The marketing communications often reaches levels of the absurd as we can see in the following example:

NetClarity (which is a NAC appliance) claims that it provides “IT Compliance Automation” and that it “Generates regulatory compliance gap analysis and differential compliance reports” and “self-assessment, auditing and policy builder tools for Visa/Mastercard PCI, GLBA (sic), HIPAA, CFR21-FDA-11,SOX-404, EO13231 government and international (ISO270001/17799) compliance.”

A network access control appliance is hardly an appropriate tool for compliance gap analysis but asserting that a NAC appliance or Web application firewall automates SOX 404 compliance is absurd.

Sarbanes-Oxley Section 404, requires management and the external auditor to report on the adequacy of the company’s internal control over financial reporting. This means that a company has to audit, document and test important financial reporting manual and automated controls. I remember the CEO of a client a few years ago insisting that he would not accept any financial reports from his accounting department unless they were automatic output from the General Ledger system – he would not accept Excel spreadsheets from his controller, since he knew that the data could be massaged and fudged. If there was a bug in the GL or missing / incorrect postings he wanted to fix the problem not cut and paste it.

Appropriate, timely and accurate financial reporting has absolutely nothing to do with network access control.


But the best part is the piece on the NetClarity Web site that claims that their product will help “Deter auditors from finding and writing up IT Security flaws on your network”.

And I suppose this really proves my point best of all.

Information security vendors like NetClarity do not have any economic incentive to really reduce data security and compliance breaches that would reduce  sales, making it better business for them  (not for their customers) to sell ineffective products.

This raises an interesting question about information security business models – but that’s a topic best left to another post.

 

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

HIPAA and cloud security

In almost every software security assessment that we do of a medical device, the question of HIPAA compliance and data security arises.  The conversation often starts with a client asking the question – “I hear that Amazon AWS is HIPAA compliant?  Isn’t that all I need?

Well – not exactly. Actually, probably not.

As Craig Balding pointed out on his blog post Is Amazon AWS Really HIPAA Compliant Today? there are some basic issues with AWS itself.

There is no customer accessible AWS API call audit log
In other words, you have no way to know if, when and from where (source IP) your AWS key was used to make API calls that may affect the security posture of your AWS resources (an exception is S3, but only if you turn on logging (off by default)).

There is no way to restrict the source IP address from which the AWS API key can be used.
The AWS API interface can be used from any source IP at any time (and as above, you have no audit trail for EC2 API calls).  This is equivalent of exposing your compute and storage management API to the entire planet.

Each AWS account is limited to a single key – unauthorized disclosure of the key results in total breakdown of security

It only gets worse.
Web services and storage are just a small part of  data security.

Even if Amazon AWS was perfect in terms of it’s data security countermeasures – there would still be plenty of opportunity for a data breach of PHI.

There are multiple attack vectors from the perspective of HIPAA compliance and PHI data security.  The following schematic gives you an idea of how an attacker can steal PHI, figure (inspired of my colleague Michel Godet) using any combination of no less than 15 attack vectors to abuse and steal PHI:

There are potential data security vulnerabilities in the client layer, transmission layer, platform layer (Operating system) and cloud services (Amazon AWS in our example).

Note that the vulnerabilities for a PHI data breach can not only happen inside any layer but in particular there are vulnerabilities in the system interfaces between layers.

Let’s take a specific example.

Consider a remote medical diagnostic service that collects information, transmits it over secure channels (https for the sake of argument) to a centralized facility for processing and diagnosis.  The entire transmission stream can be secure but if the processing and diagnosis facility uses Microsoft IIS as an interface, it is possible to attack the IIS Web server, create denial of service and exploit IIS7 and Windows operating system vulnerabilities in order to gain access to the machine itself, the data in motion and possibly gain access and compromise the internal network.

A discussion of HIPAA compliance needs to include a comprehensive threat analysis of the entire supply chain of data processing and not just limit itself to the cloud services that store electronic medical records.

For further reading, see the below resources on HIPAA compliance with Amazon Web services and work that Software Associates has done on threat modeling.

 

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

The cloud concierge

The Israeli ISPs are really really bad.  Just abysmal. It hurts me just to think about the level of customer service and data security incompetence that would make an Iraqi ISP running an operation in a store front beam with pride.

I assume that we are not the only business to suffer from Netvision (and Bezeq International and 012).

Perhaps there is a business opportunity for a “cloud concierge” service  that would provide a VIP front end to the best of the international cloud service providers but with a local presence.  The cloud concierge would help customers select and implement the right product,  application, security and provide a guaranteed SLA using unbunbled services from providers like dnsmadeeasy, rackspace and peer 1.

My wife doesn’t get it. She asks: “What is the concierge angle here?  I reply – “How do you get basketball tickets, a recommendation to a good restaurant and a local metro card in a foreign country without the hotel concierge?”

Hmm., she says. “OK, now I get it. but how are you gonna make money out of it when anyone can google for cloud services?”

Got me there babe. Right to the bottom line. Then again, she already has a celebrity stylist service to buy shoes online. Why on earth would she need a cloud concierge?

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

Application software in the cloud – power to the people

I think that it might be a novel approach to build a flat cloud security control model centered around consumers (stake holders, users and developers) of business applications software and the performance of the cloud services that they consume.

This might be a more productive and relevant control model than then the current complex, multiple layer, IT infrastructure and compliance-centric cloud security models that are being copied and pasted today.

It’s also more consistent with a technology shift towards consumer devices and services and an emerging transformation of the security industry from an end-user service industry to a B2B product.  Intel bought Mcafee. Two years ago, we still had end user customers. Today we only deal with technology vendors.

The cloud security reference model published by the CSA (Cloud Security Alliance) is a detailed and comprehensive guide to “Security for Critical Areas of Focus in Cloud Computing“.  The latest version was released in December 2009, back when Facebook had less than 80 million members.

It’s a long, eloquently written document with pearls of wisdom like:

Cloud computing is about gracefully losing control while maintaining accountability even if the operational responsibility falls upon one or more third parties.

I could not agree less.

We all use the term  “IT Governance” – as if security of  customer data was dependent on the governor of the IT department. Since we have lots of IT governance and lots of data breaches, we may safely assume that writing procedures while the hackers attack software and steal data is not an effective security countermeasure.

Management information systems, (aka Information technology) is about empowering management with information.

Cloud computing is about replacing the hegemony of management with the freedom of choice of business units.

Cloud computing has nothing to do with gracefully losing control – it’s about getting out from under the thumb of the CIO.

This is why a performance-oriented security control model is a better and more relevant fit for consumers of cloud services. What interests cloud computing consumers are the following questions:

  1. Does the application or service help me sell more, faster and cheaper with something different my customers haven’t heard yet?
  2. Can I deploy (HIPAA, PCI DSS …fill in the blanks) applications in the cloud at a price I can afford?

When we buy software application services (SaaS) using a utility model, then the security should not interest us, since it’s built in.

When we develop our own application software and run it in the cloud using an IaaS (infrastructure as a service) provider then the IT security infrastructure does not interest us, since it’s built into the infrastructure.

What should interest us  is business performance and service costs.

Neither of these are addressed in the CSA cloud security reference model, which is still fixated on familiar infrastructure controls:

This rigidity often manifests in the inability to gain parity in security control deployment in cloud environments compared to traditional IT. This stems mostly from the abstraction of infrastructure, and the lack of visibility and capability to integrate many familiar security controls — especially at the network layer.

Why should we be concerned with parity in security control deployment when I buy a service?

When we buy electricity, are we comparing our utility and safety expertise in electricity generation with the electric company?

I don’t think so.

Consider, a consumer-service provider cloud security control model that is focused  on performance.

The fundamentals of scalable cloud computing systems are fast networking and non-blocking design—the rest is message passing.

Current Web applications running in the cloud are fairly high latency (200-600 ms round trips for Ajax transactions) and demanding on the server infrastructure (forking threads and blocking IO on the Web server for every request).

Looking at business performance we know that time is money. We know that high latency applications are less responsive (making customers unhappy and reducing revenue). Since the cloud service provider charges per CPU cycle,  if the cloud service consumer deploys inefficient applications  his revenue goes down and his costs go up.

Since cloud computing is a utility, it’s a business decision to write inefficient, buggy code and pay more for the privilege.  It’s also a business decision to use services like Microsoft Azure which locks you into the Microsoft application development platforms or Salesforce.com that locks you into the SF.com way of doing things.

There is something counter-intuitive about locking yourself into a cloud computing service.  The price has to be right long term and long term may be a decision that your successor is taking.  Hmm. Food for thought.

Power to people baby.

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

3GPP Long Term Evolution – new threats or not?

3GPP Long Term Evolution (LTE), is the latest standard in the mobile network technology tree that produced the GSM/EDGE and UMTS/HSPA network technologies. It is a project of the 3rd Generation Partnership Project (3GPP), operating under a name trademarked by one of the associations within the partnership, the European Telecommunications Standards Institute.

The question is, what will be the data security  impact of LTE deployments? As LTE is IP based and IPv6 becomes more common in the marketplace, will the security requirements of mobile devices become similar to traditional networked devices?  There is already a huge trend  for BYOD or Bring Your Own Device to work, which certainly causes a lot of headaches for information security staffs. Will more bandwidth and flat IP networks of LTE increase the threat surface for corporate IT?

Other than higher performance, LTE features a flat IP network, but I don’t see how that increases the threat surface in any particular way.  The security requirements for mobile networked devices are similar to traditional wired devices but the vulnerabilities are different, namely the potential of unmanaged BYOD tablet/smartphone to be an attack vector back into the enterprise network and to be a channel for data leakage.  The introduction of Facebook smart phones is far more interesting as a new vulnerability to corporate networks than smart phones with a 100MB download and 20MB upload afforded by LTE.

I am not optimistic about the capability of a company to manage employee owned mobile devices centrally and trying to rein in smartphones and tablets with awareness programs.  Instead of trying to do the impossible or the dubious, I submit that enterprise that are serious about mobile data security must take 3 basic steps after accepting that BYOD is a fact of life and security awareness has limited utility as a security countermeasure.

  1. Reorganize physical, phones and information security into a single group with one manager.  This group must handle all data, software IT, physical (facilities) and communications issues with a single threat model driven by the business and updated quarterly. There is no point in pretending that the only phones used by employees are phones installed and operated by the companies telecom and facilities group. That functionality went out the door 10 years ago.
  2. Develop a threat model for the business – this is  key to being able to keep up with rapidly growing threats posed by BYOD.  Update that model quarterly, not yearly.
  3. CEO must take an uncompromising stance on data leaks and ethical employee behavior. It should be part of the company’s objectives, measurable in monetary terms just like increasing sales by 10% etc.

 

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

ניהול אבטחת מידע בענן – על תבונה ורגישות

ניהול אבטחת מידע בענן – על תבונה ורגישות

,ממשל נתונים הוא דרישה הכרחית להגנה על נתונים כשעוברים למחשוב בענן. קביעת מדיניות ממשל נתונים היא בעלת חשיבות מיוחדת במודל העבודה של מחשוב ענן שמבוסס על אספקת שירותים בתשלום ליחידת צריכה, בניגוד למודל המסורתי של מערכות מידע המבוסס על התקנה, שילוב מערכות ותפעול מוצרים.

יחד עם ההיצע הגדל של פתרונות מחשוב ענן זולים ובעלי ביצועים גבוהים, ישנו צורך חיוני לארגונים לנסח ולהסדיר את מדיניות ממשל הנתונים שלהם. ממשל נתונים פירושו הגדרת הבעלות על הנתונים, השליטה בגישה לנתונים, עד כמה ניתן לעקוב אחר הנתונים וציות לרגולציות, כמו למשל נתוני חולים (הגנה על מידע רפואי אישי כפי שמוגדרת בתקנות של משרד הבריאות האמריקאי).

כדי לבנות אסטרטגיית ממשל נתונים יעילה לענן, יש לענות על עשר השאלות הבאות – תוך חיפוש האיזון המתאים בין הגיון פשוט לדרישות אבטחת הנתונים:

1. מהם הנתונים היקרים ביותר בארגון? כמה כסף הם שווים?

2. כיצד מאוחסנים נתונים אלה – שרתי קבצים, שרתי מסד נתונים, מערכות ניהול מסמכים?

3. כיצד יש לנהל ולאבטח את הנתונים?

4. למי צריכה להיות גישה לנתונים?

5. למי בפועל יש גישה לנתונים?

6. מתי הייתה הפעם האחרונה שנבחנה מדיניות אבטחת המידע / הצפנה?

7. מה המתכנתים בארגון יודעים על אבטחת מידע בענן?

8. למי יש אפשרות לשנות או לטפל בנתונים? (כולל שותפים עסקיים וקבלנים)

9. במקרה של דליפה למקור בלתי מוסמך, מהו הנזק הכלכלי שיגרם לארגון?

10. במקרה של פריצה, תוך כמה זמן יאותר אירוע אובדן הנתונים?

בהקשר של ממשל נתונים בענן, רבים שואלים מה סוג הנתונים שיש לשמור בתשתית IT מקומית?”.

התשובה המוכנה והמובנת מאליה היא שמידע רגיש צריך להישמר באחסון מקומי.

למרות זאת, יתכן ועדיף לאחסן דווקא מידע רגיש מחוץ לכותלי המשרדים במקום לספק גישה מקומית לעובדים וקבלנים.

השימוש בשירותי תשתית מחשוב בענן לאחסון נתונים רגישים יכול למעשה להקטין את מרחב האיומים לאיומים במקום להגדיל אותו, ולהעניק לארגון יותר שליטה על ידי מרכוז וסטדנדרטיזציה של אחסון נתונים כחלק מאסטרטגיית ממשל נתונים מקיף.

בנוסף ניתן לשאת ולתתבחוזה מסחריעל הרכב אמצעי שליטה יעילים במסגרת חוזה מסחרי עם ספקי שירותי מחשוב ענן, מה שלא ניתן לעשות בקלות מול עובדים בארגון.

השאלה השנייה שחוזרת על עצמה לגבי אסטרטגיית ממשל נתונים בענן היא כיצד ניתן להגן על נתונים בלתי מובנים מפני פריצות?”.

באופן ברור, התשובה תלויה בארגון עצמו ומערכות הוכנה שלו.

למרות שאנליסטים כמו גרטנר טוענים שיותר מ– 80% ממידע הארגוני מאוחסן בקבצים כמו מיקרוסופט אופיס, הנתון הזה תלוי באופן טבעי בתחום העיסוק של הארגון. ספקי שרות אוגרים מרבית המידע שלהם במסדי נתוניםת ולא בקבצי אקסל.

 

אם בכלל, מרחב האיומים על מסדי נתונים גדל הרבה יותר מהר מהגידול הטבעי בקבצי אופיס. ספקי שירותים בתחום הטלקום והסלולר מחזיקים כמויות עצומות של מידע במסדיי נתונים מובנים (רשומות שיחה, רשומות שירותים ללקוח וכו‘). ככל שסמארטפונים, אנדרואיד, מחשבי לוח והתקני מחשוב ניידים יהיו נפוצים יותר, כך יגדל חלקם של הנתונים המובנים בספקי השירות למיניהם בענן. בתחום הבריאות, בעידן שכל הרשומות רפואיות אלקטרוניות, גדל עוד יותר כמות המידע הרגיש במסדי נתונים כגון אוראקל.

נוסף על כך, השימוש בטכנולוגיית מאגרי מידע גסון המתחברת ישירות ליישומי אינטרנט (נמצא בשימוש רחב בפייסבוק), גדל במהירות עצומה. שימו לב במיוחד לקאוצדיבי שיש מעל עשרה מיליון התקנות לאחר פחות משנתיים בשטח! מאגרי כאלה כאלה עלולים להיות חשופים להתקפות חדירה מסורתיות שמנצלות נקודות תורפה בזמן בנייה והרצת שאילתות.

לסיכום, כשניגשים לבנות אסטרטגיית ממשל נתונים לענן יש להתחשב בכל הנקודות שהוצגו כאן ולהתחיל על ידי מענה לעשר שאלות המפתח לאבטחת נתונים במחשוב ענן.


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

Moving your data to the cloud – sense and sensibility

Data governance  is a sine qua non to protect your data in the cloud. Data governance is of particular importance for the cloud service delivery model which is philosophically different from the traditional IT product delivery model.

In a product delivery model, it is difficult for a corporate IT group to quantify asset value and data security value at risk over time due to changes in staff, business conditions, IT infrastructure, network connectivity and software application changes.

In a service delivery model, payment is made for services consumed on a variable basis as a function of volume of transactions, storage or compute cycles. The data security and compliance requirements can be negotiated into the cloud service provider service level agreement.  This makes quantifying the costs of security countermeasures relatively straightforward since the security is built into the service and renders the application of practical threat analysis models more accessible then ever.

However – this leaves the critical question of data asset value and data governance. We believe that data governance is a primary requirement for moving your data to the cloud and a central data security countermeasure in the security and compliance portfolio of a cloud customer.

With increasing numbers of low-priced, high-performance SaaS, PaaS and IaaS cloud service offerings,  it is vital that organizations start formalizing their approach to data governance.  Data governance means defining the data ownership, data access controls, data traceability and regulatory compliance, for example PHI (protected health information as defined for HIPAA compliance).

To build an effective data governance strategy for the cloud, start by asking and answering 10 questions – striking the right balance between common sense and  data security requirements:

  1. What is your most valuable data?
  2. How is that data currently stored – file servers, database servers, document management systems?
  3. How should that data  be maintained and secured?
  4. Who should have access to that data?
  5. Who really has access to that data?
  6. When was the last time you examined your data security/encryption polices?
  7. What do your programmers know about data security in the cloud?
  8. Who can manipulate your data? (include business partners and contractors)
  9. If leaked to unauthorized parties how much would the damage cost the business?
  10. If you had a data breach – how long would it take you to detect the data loss event?

A frequent question from clients regarding data governance strategy in the cloud is “what kind of data should be retained in local IT infrastructure?”

A stock response is that obviously sensitive data should remain in local storage. But instead, consider the cost/benefit of storing the data in an infrastructure cloud service provider and not disclosing those sensitive data assets to trusted insiders, contractors and business partners.

Using a cloud service provider for storing sensitive data may actually reduce the threat surface instead of increasing it and give you more control by centralizing and standardizing data storage as part of your overall data governance strategy.

You can RFP/negotiate robust data security controls in a commercial contract with cloud service providers – something you cannot easily do with employees.

A second frequently asked question regarding data governance in the cloud is “How can we protect our unstructured data from a data breach?”

The answer is that it depends on your business and your application software.

Although analysts like Gartner have asserted that over 80% of enterprise data sets are stored in unstructured files like Microsoft Office – this is clearly very dependent on the kind of business you’re in. Arguably, none of the big data breaches happened by people stealing Excel files.

If anything, the database threat surface is growing rapidly. Telecom/cellular service providers have far more data (CDRs, customer service records etc…) in structured databases than in Office and with more smart phones, Android tablets and Chrome OS devices – this will grow even more. As hospitals move to EMR (electronic medical records), this will also soon be the case in the entire health care system where almost all sensitive data is stored in structured databases like Oracle, Microsoft SQL Server, MySQL or PostgreSQL.

Then. there is the rapidly growing  use of  MapReduce/JSON database technology used by Facebook and Digg: CouchDB (with 10 million installations) and MongoDB that connect directly to Web applications. These noSQL databases  may be vulnerable to some of the traditional injection attacks that involve string catenation. Developers are well-advised to use native APIs for building safe queries and patch frequently since the technology is developing rapidly and with large numbers of eyeballs – vulnerabilities are quickly being discovered and patched. Note the proactive approach the the Apache Foundation is taking towards CouchDB security and a recent (Feb 1, 2011) version release for a CouchDB cross-site scripting vulnerability.

So – consider these issues when building your data governance strategy for the cloud and start by asking and answering the 10 key questions for cloud data security.

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

Medical device security trends

Hot spots for medical device software security

I think that 2011 is going to be an exciting year for medical device security as the FDA gets more involved in the approval and clearance process with software-intensive medical device vendors. Considering how much data is exchanged between medical devices and customer service centers/care givers/primary clinical care teams and how vulnerable this data really is, there is a huge amount of work to be done to ensure patient safety, patient privacy and delivery of the best medical devices to patients and their care givers.

On top of a wave of new mobile devices and more compliance, some serious change is in the wings in Web services as well.

The Web application execution model is going to go through an inflection point in the next two years transitioning from stateless HTTP, heterogeneous stacks on clients and servers and message passing in the user interface (HTTP query strings) to WebSocket and HTML5 and running the application natively on the end point appliance rather than via a browser communicating to a Web server.

That’s why we are in for interesting times I believe.

Drivers
There are 4 key drivers for improving software security of medical devices, some exogenous, like security, others product-oriented like ease of use and speed of operation.  Note that end-user concerns for data security don’t seem to be a real market driver.

  1. Medical device quality (robustness, reliability,usability, ease of installation, speed of user interaction)
  2. Medical device safety (will the device kill the patient if the software fails, or be a contributing factor to damaging the patient)
  3. Medical device availability (will the device become unavailable to the user because of software bugs, security vulnerabilities that enable denial of service attacks)
  4. Patient privacy (HIPAA – aka – data security, does the device store ePHI and can this ePHI be disclosed as a result of malicious attacks by insiders and hackers on the device)

Against the backdrop of these 4 drivers, I see 4 key verticals: embedded devices, mobile applications, implanted devices and Web applications.

Verticals

Embedded devices (Device connected to patient)

  1. Operating systems, Windows vs. Linux
  2. Connectivity and integration into enterprise hospital networks: guidelines?
  3. Hardening the application verus bolting on security with anti-virus and network segmentation

Medical applications on mobile consumer devices (Device held in patient hand)

  1. iPhone and Android – for example, Epocrates for Android
  2. Software vulnerabilities that might endanger patient health
  3. Is the Apple Store, Android Market a back door for medical device software with vulnerabilities?
  4. Application Protocols/message passing methods
  5. Use of secure tokens for data exchange
  6. Use of distributed databases like CouchDB to store synchronized data in a head end data provider and in the mobile device The vulnerability is primarily patient privacy since a distributed setup like this probably increases total system reliability rather than decreasing it. For the sake of discussion, CouchDB is already installed on 10 million devices world wide and it is a given that data will be pushed out and stored at the end point hand held application.

Implanted devices (Device inside patient)

  1. For example ICD (implanted cardiac defibrillators)
  2. Software bugs that results in vulnerabilities that might endanger patient health
  3. Design flaws (software, hardware, software+hardware) that might endanger patient health
  4. Vulnerability to denial of service attacks, remote control attacks when the ICD is connected for remote
  5. programming using GSM connectivity

Web applications  (Patient interacting with remote Web application using a browser)

  1. Software vulnerabilities that might endanger patient health because of a wrong diagnosis
  2. Application Protocols/message passing methods
  3. Use of secure tokens for data exchange
  4. Use cloud computing as service delivery model.

In addition, there are several “horizontal” areas of concern, where I believe the FDA may be involved or getting involved

  1. Software security assessment standards
  2. Penetration testing
  3. Security audit
  4. Security metrics
  5. UI standards
  6. Message passing standards between remote processes
Tell your friends and colleagues about us. Thanks!
Share this