Security Challenges of RFID by Muni Tripathi, CISSP

Radio Frequency Identification (RFID) technology is popular with many retailers and the consumer-products manufacturers. However, RFID technology is not very secure at present. So far, there have been no known reports of security breaches, but how long can we remain complacent? Lack of security and high cost to incorporate it is a big hurdle in further making this technology popular. 

The main security concerns with RFID are the interception of information in the clear as it travels from RFID reader to the network, reprogramming of chips to alter the information contained and the high impact of breaches. A hack in RFID network may potentially have far bigger impact in the supply chain than an isolated event of manual errors.  The breaches can happen at the RFID tag, network or data level. A major problem in putting latest security technology on the chip is its limited processing power. The existing security solutions demand too much CPU power. Although technology and systems exist that can perform the necessary security tasks efficiently (such as IPSEC and SSL accelerators), these systems are expensive. So development of security technology, which can fit in the space, and cost requirements of supply chain systems is necessary to provide peace of mind to users.  

There have been rumors in the law enforcement circles that hijackers of cargo trucks are using RFID readers to locate high value items to steal. Supply chain data could be corrupted by rogue RFID tags, change its data to random in a denial of service attack. Not everything is as bad as it sounds though, RFID does provide higher level of security but it’s mostly security by obscurity. Once the use of technology reaches a turning point, there will be more incentive for people with malicious intent to launch attacks and then obscurity no longer will work. Unlike bar codes RFID tags are harder to counterfeit. One needs knowledge and right set of tools to counterfeit RFID. Imagine what happens when RFID becomes a common use technology and it is using insecure wireless channels. Potential for damage is huge and supply chains of the companies who depend on RFID can be compromised resulting in huge losses. This is no longer a pipe dream; many of the world’s retail chains are routinely using RFID in their supply chain. 

RFID systems mainly have three components, RFID tags, RFID readers, and RFID servers that process the data and store it. Securing RFID server requires same level of security as any other server. Access to servers should be authenticated and communication channel should be secure to have security guarantee. Solving both of these problems points us in the direction of RFID readers, readers are the devices which read the data from tags and send back relevant information to server over a network. This communication channel whether it’s wired or wireless can be secured with the use of SSL or SSH. The weak link in the chain of security is RFID tag. The RFID tags allow reading the information off of them to a reader.  There is no authorization check or authentication to prevent leaking the information to a drive by RFID reader. Similarly, information on RFID tags can also be modified by unauthorized entities. 

There are few potential solutions to fix the security issues surrounding tags but none of them is foolproof. One of the ways is to kill the tags, the tags are de-activated at the checkout, and thus users of the merchandise do not broadcast information about where they bought their items. However, it does not solve the problem of using the tags within the supply chain. Another solution is to use light weight authentication methods which are suitable for the low processing power environment. This is an active area of research. We can hope to see some innovative new solutions coming to the market in next few years that will solve the security issues and will make the use of RFID more popular. 

References:

http://www.informationweek.com/story/showArticle.jhtml?articleID=52601030&tid=13690

http://www.ccmsectorinvest.com/detailednews.asp?intReleaseID=8704&d=11*2005&n=36

The best-managed projects are finished under budget, in time, with great quality and within scope. The seed of such a successful project is sowed when defining the scope. Define the scope too big or vague and project is doomed for failure. Define it too narrow, and it may not satisfy the requirements it set out to meet. A good project scope requires a clear vision of what is expected out of the security posture of the company, although only vision is not sufficient to determine the scope. 

An example of a security vision of a company is “secure all company and customer data from potential breaches and unauthorized disclosure”.  This is a good vision, but it is a bad project scope. There can be many security projects to fulfill this vision, each with its own scope. The scope of a project to create a security perimeter for the company is very different from a project to secure data at rest, although each partially fulfills the company’s security vision. A good project scope is specific and creates an image of the desired goal. To take the above example of  “securing data at rest“ project scope; this scope is still too broad. What at rest data is to be secured? Is it database, a file system, user’s PCs, removable media such as DVDs, USB devices? One may conclude that it is not possible to secure every possible media, therefore restrict the scope to database, and put other mechanisms in place to prevent compromise of data. Point is, in order for a security project to be successful; scope should be very clear and should have buy in from stakeholders. 

As happens with many projects, security projects are expected to be complete yesterday, not tomorrow. Therefore, it is extremely important to set the right expectations from the start with all stakeholders. Follow the mantra of under promise and over deliver. In long run, this builds credibility with management and engenders trust. If it appears that there are too many things to do and scope is big, take a deep breath and follow divide and conquer. There is no rulebook that says that everything has to be done as part of one project. Divide the security objectives you are trying to achieve and make them different projects. Implement security in a phased manner and make use of third party vendors to offload your work wherever necessary. Of course, all this requires buy in from stakeholders, so keep them in the loop. 

Despite everything one does to keep the scope under control, there will be moments when one has to make a choice and go against expectations from management. It takes lot of courage to stand up and tell the management truth that a project will take longer especially when expectations are high. But it must be done for the success of a project. It is better to keep everything in open as far any doubts or hesitations are concerned rather than thinking it can be figured out later. Every single item, that is left unclear or in doubt shall come to bite later. All stakeholders will be happy to know about any problem sooner and be grateful that you pointed them out. 

(continued)

Revocation Checks for Digital Certificates by Muni Tripathi, CISSP  

When logging onto a secure site (https url) web server sends a digital certificate to browser. Many of us will be familiar with security related browser pop-ups that complain about some error in a certificate. In one of the previous write ups I mentioned about the checks browser perform to validate the authenticity of web server. Those checks include, verifying hostname in certificate against the name of the server user is visiting, verifying that certificate has not expired and that it is issued by a trusted CA. Even after all these checks; potential of a security hole in certificate verification process remains. What if the certificate has been revoked by issuing CA? Unless certificate verification process checks with a CA for revocation information, there is no guarantee that web server certificate is still valid even though all other verifications were successful. 

Although it is a known problem, most of the existing browsers do not perform revocation check by default because of the difficulty of maintaining and collecting revocation information. Let us look at a simplistic view of revocation process. Typically, revocation information is distributed in the form of CRL (certificate revocation list) which is hosted on a known web server. CRL can be downloaded from web server periodically and installed with revocation checking turned on. But, the process is tedious and error prone, hence not very scalable. However, in an environment of stringent security requirements, it still provides a workable solution. 

An improvement over the process is to include the revocation server information (called CRL server) in the certificate itself. Server information is extracted from certificate at the time of verification and CRL is downloaded automatically and certificate is verified against it. This is better, but it leads to scalability problems for huge CRLs. What if the CRL is large (ex. 10MB, it is not an unrealistic number, some environments do have CRLs this big)? Downloading complete CRL for all certificate verifications is not practical anymore. Therefore, CRL information is also distributed in partial chunks called delta CRLs, which is updated on a periodic basis. Delta CRL contains information about certificates revoked since last delta CRL or CRL, as the case might be, it is smaller in size and can be downloaded more efficiently. 

There is one more issue which is not handled by CRL and delta CRL scheme. What is it? How is it solved? Stay tuned until next week.

Revocation Checks for Digital Certificates by Muni Tripathi, CISSP  

When logging onto a secure site (https url) web server sends a digital certificate to browser. Many of us will be familiar with security related browser pop-ups that complain about some error in a certificate. In one of the previous write ups I mentioned about the checks browser perform to validate the authenticity of web server. Those checks include, verifying hostname in certificate against the name of the server user is visiting, verifying that certificate has not expired and that it is issued by a trusted CA. Even after all these checks; potential of a security hole in certificate verification process remains. What if the certificate has been revoked by issuing CA? Unless certificate verification process checks with a CA for revocation information, there is no guarantee that web server certificate is still valid even though all other verifications were successful. 

Although it is a known problem, most of the existing browsers do not perform revocation check by default because of the difficulty of maintaining and collecting revocation information. Let us look at a simplistic view of revocation process. Typically, revocation information is distributed in the form of CRL (certificate revocation list) which is hosted on a known web server. CRL can be downloaded from web server periodically and installed with revocation checking turned on. But, the process is tedious and error prone, hence not very scalable. However, in an environment of stringent security requirements, it still provides a workable solution. 

An improvement over the process is to include the revocation server information (called CRL server) in the certificate itself. Server information is extracted from certificate at the time of verification and CRL is downloaded automatically and certificate is verified against it. This is better, but it leads to scalability problems for huge CRLs. What if the CRL is large (ex. 10MB, it is not an unrealistic number, some environments do have CRLs this big)? Downloading complete CRL for all certificate verifications is not practical anymore. Therefore, CRL information is also distributed in partial chunks called delta CRLs, which is updated on a periodic basis. Delta CRL contains information about certificates revoked since last delta CRL or CRL, as the case might be, it is smaller in size and can be downloaded more efficiently. 

There is one more issue which is not handled by CRL and delta CRL scheme. What is it? How is it solved? Stay tuned until next week.

Economic Impact of Cyber Attacks by Muni Tripathi, CISSP

Determining economic impact of cyber-attacks is one of the toughest tasks because comprehensive data for cyber attacks are hard to come by. Most of the organizations do not make the security breach information public until it is required by the law or may compromise customer information. This makes the task of determining the real cost of cyber attacks and security breaches extremely hard. Based on some previous research and empirical numbers, several computer security firms produce estimate of total worldwide losses. The 2003 estimates pegged the loss ranging from $13 billion (from worms and viruses only) to $226 billion (from all forms of overt attacks). Length of the attacks contributes to the costs of the cyber attacks. Short lived attacks have small impact while longer lasting attacks increase the cost in terms of lost productivity, downtime and time spent in incident response. 

One of the ways, risk can be mitigated is to buy cyber-attack insurance. There are not many insurers who provide this service due to the inexact nature of determining cost of cyber-attacks. Insurance industry has been trying to develop policies for covering cyber attacks. But there task is made harder by the lack of statistical data; organizations have strong incentives to hide information about cyber-attacks, and there are significant uncertainties and measurement difficulties that limit the ability to specify the dollar amount at risk from information security breaches. Organizations have many reasons not to report security breaches that range from limiting financial market impact, avoiding bad reputation, avoiding litigations, and liability concerns. Another strong reason not to make security breach public is to reduce chances of further attacks; if attackers know about breach, they can conclude that cyber defenses of the organization are weak and launch more attacks. 

The businesses, which primarily rely on cyber world such as online retailers and service providers, are worst hit by the occurrence of cyber-attack. The extent to which a business is affected by cyber-attacks depends on the type of attack. One of the many attacks is "DOS" (denial of service) attack. This kind of attack causes a firm's Internet business portal to be unavailable resulting in significant revenue loss. Other kinds of attacks that are even more destructive include theft or destruction of secure information. The more dependent a firm is on the Internet, and the more intrusive attack is, the more likely it is that an attack will have significant consequences for the financial health of that firm. 

Over the years, research has brought out the interesting observation that firms, which are victims of publicly known cyber-attacks, end up losing value (by 2.1 %) as compared to unaffected firms. Studies have found that there was a significant decline in stock prices of affected firms in the days immediately following a cyber-attack. Actual cost of the attacks has been also wildly varying for different kind of attacks. The real cost of an attack can be perhaps be only judged by the organizations suffering from attacks. 

Attribution: Above write up borrows from "CRS report for congress: The Economic Impact of Cyber-Attacks”. For more interesting details and numbers, refer the aforementioned document at: http://www.cisco.com/web/about/gov/downloads/779/govtaffairs/images/CRS_Cyber_Attacks.pdf 

I would like to thank Ravi for pointing me to this report.

Goals of Network and Data Security – Pa rt 2  by Muni Tripathi, CISSP

It is time to analyze the banking transaction scenario. You went to bank without revealing to anyone, why you are going there whether to deposit or withdraw money and how much. Hence, your transaction is private, only you and anybody you told about it are the people who know about it. This is achieving the goal of ‘privacy’, also called ‘confidentiality’. Notice that privacy does not end with you not revealing the transaction. Bank also has to keep all the transactions private. Privacy is a two way street. It will do no good, if bank is publishing all your information and transactions in public.  

When you present your id to the teller, he/she verifies that you are the same person as the account holder.  This is called ‘authentication’. Bank is authenticating you, verifying that you are who you claim to be. An important thing to notice here is the method of authentication is your id that is issued by a trusted third party (DMV in most cases) that bank (and everybody) is willing to trust. We shall again encounter trusted third party concept when we talk about authentication in context of network security protocols. There, however trusted third party will be ‘root certifiate authority’ (Root CA) instead of DMV. 

When you count the money to check that you got the same amount as asked, you are verifying correctness of the amount. In network security domain, verifying correctness of the data received at destination is called ‘integrity’ check. If you got wrong amount of money, your bank transaction is incorrect (teller may have made a mistake). While transferring data over network, it is worse due to lack of human interaction. Unless there is a mechanism to perform integrity checks, you can never be sure that online data has not been modified in transit. If you were depositing money in your online bank account, without integrity check it may be possible to change it to withdrawal or alter your transaction in other ways. (What happens when data is at rest? How does bank know that no one has modified it after the transaction was performed?) 

Another consideration was that bank should be solvent when you go to bank to make a transaction. In other terms, bank is ‘available’ at the time of transaction. This concept is called ‘availability’ in network security domain. Bank’s working hours also determine its availability. Outside of working hours, you can not go to a bank (well, you can drive up to the building, but it’s futile as far as your big transaction is concerned). With online systems however; expectations of availability are higher, typically 24/7. Imagine, if amazon or ebay sites were not available for an hour. How much impact does it have on their revenue? 

Finally, bank was able to prove that you made the aforesaid transaction and no one else. How they do it? By asking you to sign on papers, your signature is a written proof that you personally came into the bank. If you deny it later on, they can call handwriting experts and prove that it was only you who was at the bank. This, in security parlance is called ‘non repudiation’ i.e. you can not deny your actions. This is also one of the security goals of many networking security protocols, but optional many times. All applications do not need to have non-repudiation functionality. Who cares if you buy some stuff on ebay and later deny that it was not you? (if FBI cared, they will find other ways to prove it). Non-repudiation is required in cases where two parties are entering into a binding agreement or in matters of accountability. 

To summarize, confidentiality is one of the primary goals of online transactions for data in transit and data at rest. Authentication mechanisms are used to establish trust between online entities and integrity mechanisms are used to verify correctness of online exchanges and/or data. Then there are goals of availability and non-repudiation. One more security goal, which may be useful in specific applications, is called perfect forward secrecy (PFS). Need to find more? Time to log onto Google.

Developing Secure Applications Part 4 by Muni Tripathi, CISSP

10. Handle exceptions, errors and failures securely 

A lot of code in any application is written to handle error conditions. This creates security holes if error handling code does not take proper care to keep the security environment consistent. It is important to leave the system in a valid and consistent security state in the event of errors and exceptions. A common mistake is to reveal too much information about the system under exception conditions. Here are some things which should be handled under exceptions.

An application handling the security keys should remove and zero out the keys under conditions of unrecoverable exception. Failing to do so may leave the keys in memory even if application is no longer using it and may lead to compromise of application security. A web interface should not reveal information about database schema or tables in the backend if illegal queries are submitted. A backend database application should commit only complete transactions and have rollback mechanisms in place to avoid inconsistent data due to partial transactions. 

11. Develop a security testing strategy 

Developing Secure Applications Part 3 by Muni Tripathi, CISSP

7. Follow “less the better” approach 

Useful applications come with many features, some commonly used and some obscure. Typically 80% of the users use 20% features of the application. Application developers should follow the mantra of least feature installation for enhanced security. This is somewhat similar to the principle of ‘using secure default configuration’, but goes deeper. When an application is installed, only the minimum required set of components should be installed by default, user should be asked and given a choice for installation of advanced components. (To read about the recent brouhaha on installing hidden components, go to story of Sony BMG, http://www.schneier.com/essay-094.html). For most users, minimum installation will be good enough. For advanced users, they will know what extra features to install. If you are writing network applications, be extra careful. Networked applications are by definition exposed to threats; hence this principle becomes more important. 

8. Follow “least privilege” principle 

An application should run with only the privileges it requires. Not only this is necessary to prevent against intentional misuse by attackers but it also protects against unintentional mistakes committed by users. Within an application, not all of the code needs to run at the same privilege level. Depending on the resources used, different code segments may require different privilege levels. Application should be architected and implemented to keep this logical separation. It also provides other side benefits in ease of debugging and in adding auditing feature; ex. in a front end application, different access levels can be used for displaying read only data and read-write data (which could in turn be tied to user id). 

For an application that makes calls to an external component (using DLLs or shared libraries), it should grant restricted permissions for allowed tasks only. This may require language level or Operating Systems support. Use where ever this support is provided. 

9. Have multiple access levels 

This is an extension of the principle of ‘least privilege’ at user level. A user should not be given more access rights than he requires. An application needs to define the access control methods it supports. Typically, role based access control is used in enterprise applications. Role based access control implies that a user is given access rights to the application based on his role in the organization; ex. in an employee management system, a regular employee can access only his records and a manager may have access to records of all his subordinates. One popular method to enforce role based access control in a centralized manner uses RADIUS/TACACS servers. Administrators of the system should be given clear instructions on how to manage application roles (create, modify, delete etc.) and application should correctly enforce the access to data based on those roles. 

(Continued next week…)

4. Protect Against Buffer Overflows

Programs manipulate data in memory buffers. When data size that is being handled, exceeds the expected size, it results in internal memory buffer overflows. A skillful attacker can carefully craft the data to exploit buffer overflows and execute malicious code. Most of these attacks can be automated with tools and non skilled attackers only need to know how to use these tools. A typical vulnerability introduced by buffer overflow is escalation of privileges (admin access on windows, root access on Unix/Linux) to the system. Once an attacker has highest level of access on a system, it’s a cakewalk to compromise it further. 

Buffer overflow problems can be avoided by checking the bounds for memory region where data is being written. This can be either done by programmer explicitly or provided as a language feature. A great number of security problems are caused by this category and application’s security is significantly increased by making it buffer overflow proof. 

5. Use Secure Default Configuration

Insecure defaults are common cause of compromised systems and loss of security. Microsoft has been notorious in the past for shipping software (e.x. Windows) with services, which a user may never use, running by default. But bad guys certainly find out about such services and have a good time exploiting those. Things have changed for the better in recent times and newer software from Microsoft ship with relatively secure default configurations, where user is allowed to choose the services rather than running everything by default. Most of the applications ship with multiple configurations/services, hence using secure defaults is important for all application vendors, not just Microsoft. 

Using secure defaults is more difficult in practice than it sounds, mainly due to insecure configurations propagated in earlier generations of software. When later version of software suddenly changes the default behavior, end user’s application may stop working or break due to hidden dependencies. It can be a time consuming task to fix those issues, and it’s certainly worth the effort. Application developers should make sure that only absolute minimum services or configuration is provided at setup time and user is prompted to explicitly enable the functionality which he wants to use, rather than enabling it by default.  

6. Force to change default password

All software products without exception ship either with a default password or an empty password. If default password is not changed at the time of installation, system is a very easy target for attackers. A well intentioned administrator may simply forget or put password change in his to do list due to deadline pressures. Regardless, it opens vulnerability in the system. Therefore, application developers (vendors) must force the default password change at the time of installation or first use. Any system administrator worth his salt will prefer to be forced to change the default password and appreciate the security posture of the product. 

Continued next week…

Developing Secure Applications by Muni Tripathi, CISSP

Security risks in a system can come from variety of sources. It can come from a weakness in user interaction with the system, interdependencies of different components in the system, or from the implementation of the system itself. Here, we look at some of the vulnerabilities that can be introduced in the system implementation resulting in security risks. These vulnerabilities remain same across different software development paradigms and languages used for implementation.  

1. Never Trust User Input

User input in an application must be validated against input rules of the application. A malformed input, if accepted unchecked in an application may provide window of opportunity for an attacker. To illustrate this with an example, an input field, accepting person’s name can only consist of alphabetic and perhaps numeric characters. Allowing special characters such as dollar ($) and star (*) can lead to very nasty attacks depending on the type of application. In many computer languages, special characters have special meanings, which if used inappropriately can compromise the integrity and availability of data.  

2. Be Careful With Output

Output information that is necessary to perform a task for a user. To take the common example, passwords should never be shown on the screen when either setting it first time or later used for logging into the system. What data to display on a user interface and what not, is highly application dependent, still  “need to know” can be used as a general guideline. A user should be allowed access to only information that he or she needs to know in order to complete his task and no more. A security conscious application should validate access control before outputting data. 

3. Trust Experts for Crypto Implementation

Many applications use cryptographic libraries to perform