Tuesday, October 25, 2011
What holds you from moving to the cloud?
The following list of concerns are from 2008. Has it changed in 2011 or still the same??
Thursday, October 6, 2011
Secure programming tips - reduce attack surface
The attack surface in software refers to the code an unauthenticated user can run. (What can an unauthenticated (malicious/untrusted) user do without having access to the system?)
For web forms,
- ALWAYS validate user inputs
- ALWAYS use the least possible privileged access to the resources (if a database connection only requires read only user, make sure that the web forms are connected to the database through a read only database user that read only from a specific database.)
- NEVER show exceptions on the browser as they may reveal useful information to an attacker to look for different attack vectors.
For any code,
- ALWAYS implement whitelisting approach (i.e. always give access based on the credentials users have)
- WEAR the "untrusted user" hat when writing code
- ONLY use libraries that are known to be secure
- THINK about the attack surface from the first line of code
If it is a service interface,
- Have the bare minimum number of functions (this will reduce the number of entry points for an untrusted user) - if a function is not going to be used by any user, just remove it.
For web forms,
- ALWAYS validate user inputs
- ALWAYS use the least possible privileged access to the resources (if a database connection only requires read only user, make sure that the web forms are connected to the database through a read only database user that read only from a specific database.)
- NEVER show exceptions on the browser as they may reveal useful information to an attacker to look for different attack vectors.
For any code,
- ALWAYS implement whitelisting approach (i.e. always give access based on the credentials users have)
- WEAR the "untrusted user" hat when writing code
- ONLY use libraries that are known to be secure
- THINK about the attack surface from the first line of code
If it is a service interface,
- Have the bare minimum number of functions (this will reduce the number of entry points for an untrusted user) - if a function is not going to be used by any user, just remove it.
Wednesday, October 5, 2011
Smart Meters and Privacy
In case you haven't heard about smart meters, they are the next generation electric meters. Unlike the traditional electric meters, the provide two way communication. The goal of smart meters is to allow utility companies and consumers to better monitor the energy consumption and control electricity. Smart meters act as surveillance devices. Having such a surveillance device at your home could seriously invade your privacy though. It can be a security threat as well. Here are a couple of possible threats:
- It allows a third-party to see what equipments you are using, what time of the day, how long, how often, etc.
- An insurance company inferring what kind of medical problems you have based on the devices use and what time.
- A producer marketing products that go along with your equipments or suggest different equipments
- It gives information to a burglar to figure out a best time to break in. (Low consumption may be linked to empty house.)
The question is how much information utility companies need in order to better manage electricity while protecting the privacy? In other words, how can we balance the benefits of smart meters and the risks of using them?
- It allows a third-party to see what equipments you are using, what time of the day, how long, how often, etc.
- An insurance company inferring what kind of medical problems you have based on the devices use and what time.
- A producer marketing products that go along with your equipments or suggest different equipments
- It gives information to a burglar to figure out a best time to break in. (Low consumption may be linked to empty house.)
The question is how much information utility companies need in order to better manage electricity while protecting the privacy? In other words, how can we balance the benefits of smart meters and the risks of using them?
Friday, September 23, 2011
Saturday, May 28, 2011
HIPAA compliance
Recently I have been reading a lot of HIPAA privacy/security related technical documents. HIPAA stands for Health Insurance Portability and Accountability Act and aims to protect Protected Healthcare Information (PHI) of US residents. These PHI records are held by insurers, health care clearing houses (e.g. billing services, health care information systems), health care providers, pharmacies, and so on. They are called "covered entities". So, covered entities have your sensitive PHI records. While HIPAA has many rules and regulations, I am particularly interested in HIPAA privacy and security specifications.
Before we go into "how", we first need to understand "what". Specifically,
What is PHI?
What is HIPAA privacy rule?
What is HIPAA security rule?
What does it mean to be HIPAA compliant (only the technical part)?
PHI is any health care related information (health status, medication, payments, etc.) that is held by covered entities that can be linked to an individual user.
HIPAA privacy rules consist of a set of regulations that control the use and disclosure of PHI records held by covered entities. For example, upon request, covered entities should disclose PHI to the individual. Another example, covered entities should inform individuals the use of their PHI records. Recently I had to take an x-ray; the x-ray was transferred electronically between two hospitals (from the one I took it to another hospital that I consulted a doctor). During that process I didn't get to see my x-ray, nor I was aware that it was transferred to the second hospital until I was told by the doctor I consulted that he had a look at my x-ray. To me this is a violation of HIPAA privacy rules as I was not informed beforehand by the first hospital about the use of my x-ray (i.e. PHI record).
HIPAA security rules specify a set of security standards along with either required or addressable specifications. It is primarily concerned with electronic PHI (ePHI) records. For example, it is required to implement auditing and it is an addressable to implement integrity controls. When a safeguard is "required", it should be implemented as specified by the HIPAA security rules, whereas when a safeguard is "addressable", it provide the flexibility to the covered entity to implement the safeguard as deemed appropriate. Note that it is a difficult thing to quantify how much security is required to implement a addressable security rule. Further, it is questionable how one can verify if the implementation of an addressable security safeguard complies with HIPAA rules.
HIPAA security rules are divided into three categories:
1. Administrative safeguards
2. Physical safeguards
3. Technical safeguards
We will focus only on the technical safeguards. In order to be technically HIPAA security compliant, a covered entity should implement all the required safeguards as specified and all the addressable safeguards as deemed appropriate.
Required safeguards:
- Access control
- Unique user identification
- Emergency access procedures
- Audit control
- Person/Entity authentication
Addressable safeguards:
- Access control
- Automatic logoff
- Encryption/decryption
- Integrity (incorrect modifications by authorized users)
-Transmission security
- Integrity controls (unauthorized modif
- Encryption
So, according to the above safeguards, do we need to encrypt PHIs in a closed system which does not travel through an open network? In theory, HIPAA does not specify to. But what about preventing unauthorized access to PHIs? For example, even in a close system, there are individual who should not see PHI records. For example, a database administrator should not see the PHIs stored. Therefore, it is safe to keep the PHI records in encrypted form even in the database (data at rest). Note that data in motion through open networks must be encrypted always to prevent unauthorized access to the PHI records by eavesdroppers.
Having audit controls in place is a required requirement of the technical safeguards. However, HIPAA rules do not specify what or how often should be audited. These are important decisions a covered entity should make based on the risk analysis.
Main References:
http://www.hipaaacademy.net/consulting/hipaaSecurityRuleOverview.html
http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf
Before we go into "how", we first need to understand "what". Specifically,
What is PHI?
What is HIPAA privacy rule?
What is HIPAA security rule?
What does it mean to be HIPAA compliant (only the technical part)?
PHI is any health care related information (health status, medication, payments, etc.) that is held by covered entities that can be linked to an individual user.
HIPAA privacy rules consist of a set of regulations that control the use and disclosure of PHI records held by covered entities. For example, upon request, covered entities should disclose PHI to the individual. Another example, covered entities should inform individuals the use of their PHI records. Recently I had to take an x-ray; the x-ray was transferred electronically between two hospitals (from the one I took it to another hospital that I consulted a doctor). During that process I didn't get to see my x-ray, nor I was aware that it was transferred to the second hospital until I was told by the doctor I consulted that he had a look at my x-ray. To me this is a violation of HIPAA privacy rules as I was not informed beforehand by the first hospital about the use of my x-ray (i.e. PHI record).
HIPAA security rules specify a set of security standards along with either required or addressable specifications. It is primarily concerned with electronic PHI (ePHI) records. For example, it is required to implement auditing and it is an addressable to implement integrity controls. When a safeguard is "required", it should be implemented as specified by the HIPAA security rules, whereas when a safeguard is "addressable", it provide the flexibility to the covered entity to implement the safeguard as deemed appropriate. Note that it is a difficult thing to quantify how much security is required to implement a addressable security rule. Further, it is questionable how one can verify if the implementation of an addressable security safeguard complies with HIPAA rules.
HIPAA security rules are divided into three categories:
1. Administrative safeguards
2. Physical safeguards
3. Technical safeguards
We will focus only on the technical safeguards. In order to be technically HIPAA security compliant, a covered entity should implement all the required safeguards as specified and all the addressable safeguards as deemed appropriate.
Required safeguards:
- Access control
- Unique user identification
- Emergency access procedures
- Audit control
- Person/Entity authentication
Addressable safeguards:
- Access control
- Automatic logoff
- Encryption/decryption
- Integrity (incorrect modifications by authorized users)
-Transmission security
- Integrity controls (unauthorized modif
- Encryption
So, according to the above safeguards, do we need to encrypt PHIs in a closed system which does not travel through an open network? In theory, HIPAA does not specify to. But what about preventing unauthorized access to PHIs? For example, even in a close system, there are individual who should not see PHI records. For example, a database administrator should not see the PHIs stored. Therefore, it is safe to keep the PHI records in encrypted form even in the database (data at rest). Note that data in motion through open networks must be encrypted always to prevent unauthorized access to the PHI records by eavesdroppers.
Having audit controls in place is a required requirement of the technical safeguards. However, HIPAA rules do not specify what or how often should be audited. These are important decisions a covered entity should make based on the risk analysis.
Main References:
http://www.hipaaacademy.net/consulting/hipaaSecurityRuleOverview.html
http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf
Subscribe to:
Posts (Atom)