tag:blogger.com,1999:blog-86098607397209778542024-02-20T18:21:52.766-08:00Secure the worldA security software engineer's thoughts on the security aspects of information technologyUnknownnoreply@blogger.comBlogger29125tag:blogger.com,1999:blog-8609860739720977854.post-45488089777945252892014-09-19T14:29:00.000-07:002017-04-27T12:05:16.159-07:00Musings on Apple Pay<div dir="ltr" style="text-align: left;" trbidi="on">
I have waited several years for Apple Pay and am glad it is finally here. What I am not so happy about it uses NFC and hence works only on iPhone6 :-( Ostensibly, this is for "security" (and there is mention of "secure storage" as well) but I question that.<br />
<br />
<b>Secure Storage</b><br />
I think even the iPhone 3GS has reasonably secure storage to store any private keys that may be needed to generate one-time transaction authorization codes.<br />
<br />
<b>Barcodes, WiFi, Bluetooth</b><br />
The random token can be sent to the payment terminal using a barcode displayed on the screen and still be as secure It can use WiFi or Bluetooth as well. Barcode at first glance would appear to be a one-way channel but the phone has a camera too (in case we want the payer to check if the payee is legit, but I don't think that is done or needed for credit card payments). [<b>Update April 2017</b>: PayTM in India is using an NFC free solution and a 2D barcode to identify the seller]. WiFi might be tricky if a user is on a network different from the one the payment terminal wants to use and it is not as power-efficient as Bluetooth. Barcode has the advantage that existing payment terminals with Barcode readers can be updated to Apple Pay with software changes.<br />
<br />
<b>User Experience</b><br />
One might argue that a barcode based system would be a less appealing user experience than a radio based one. However, I fail to see why Bluetooth would not achieve the same. Why did Apple choose to have another component in the system? Perhaps because there is an installed base of NFC payment terminals? I doubt that.<br />
<br />
<b>Why Security Matters? Consumer is not on the hook for that</b><br />
We all know that we are not responsible for fraudulent charges on credit cards. That burden is borne (rightfully so) by the payment processing industry. However, they pass on the cost of fraud to merchants as high transaction fees and the merchants pass that on to consumers. By designing a system that is more secure than the physical credit card (at least those common in the US), Apple was able to convince the payment processors to give it discounts on transaction fees. Of course, it will not translate to lower prices for consumers anytime soon (sigh!) but the payment industry needs a lot of shaking up. 1-3% processing fee is ridiculously high in the electronic age.<br />
<br />
<b>Conclusion</b><br />
I hope that Apple starts supporting Bluetooth based Apple Pay in the future because I believe it will be as good as NFC.</div>
<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-21884063540745346512013-08-07T14:30:00.001-07:002013-08-07T14:30:51.501-07:00Plaintext passwords<div dir="ltr" style="text-align: left;" trbidi="on">
I saw <a href="http://www.siliconbeat.com/2013/08/07/chrome-password-security-found-to-be-flawed-but-google-basically-says-arent-we-all/" target="_blank">this</a> (and <a href="http://blog.elliottkember.com/chromes-insane-password-security-strategy" target="_blank">this</a>) and instantly thought: seems fair, if you saved the password for a site then anyone with access to the browser can log in to the site. So why not display the password in plaintext if a user wants to see it? The only reason would be to allow users to save a password for a less important site and use the same password on a more important one. That way, if someone got access to the browser they can login to the less important site but not the more important one.<br />
<br />
The tradeoff, however, is that showing the password is a great usability feature. If I save the password, I tend to forget it and when I want to log in from somewhere else I need to see the saved one. The Chrome developers chose usability for this case. I would do the same. In fact, I would be upset if I cannot see the password when I want to see it. [Some banks don't let you see your own account number when you log in and I find that silly and upsetting.]<br />
<br />
I think the confusion arises from the publicity given to some data breaches where passwords were not encrypted or were hashed without salt. This issue is clearly different from the browser's saved password feature. This issue is comparable to a thief getting access to everyone's money in a bank while the browser issue is more like me getting to count the money in my wallet.</div>
<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-38284915468825149492013-03-07T18:53:00.004-08:002013-03-07T18:53:59.922-08:00Samsung KNOX - security by obscurity?<div dir="ltr" style="text-align: left;" trbidi="on">
Samsung is finally getting <a href="http://www.samsung.com/global/business/mobile/samsungknox/index.html" target="_blank">serious</a> about security. Most people don't realize that Apple has <a href="http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf" target="_blank">had</a> it for a while. I <a href="http://securetheworld.blogspot.com/2012/07/ios-security-pros-and-cons.html" target="_blank">blogged</a> about it a few months ago. One of the cons of Apple's solution was the lack of a mobile device management (MDM) solution of its own. Samsung KNOX seems to have some part of that baked in while relying on "<span style="background-color: white; font-family: Arial; font-size: 12px; line-height: 18px;">enterprise preferred MDM vendor solution"</span> to complete the solution.<br />
<br />
It is not clear to me if KNOX is as good as iOS. It is nice that the files are encrypted but that is no use of the keys are easily accessed by an adversary. It is not clear how they are stored in the KNOX design. Apple's design is good: keys are generated randomly at factory and stored securely in the chip. If KNOX doesn't get this right, there is no value in its MDM or other security features. Until Samsung documents that part openly, I would call it security by obscurity...or security by marcom (marketing communications) :-)</div>
<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-33498852346877653172012-07-27T16:08:00.003-07:002012-07-27T16:08:44.142-07:00iOS security pros and cons<div dir="ltr" style="text-align: left;" trbidi="on">
Security via obscurity doesn't stand up to the test of time. Apple has released a <a href="http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf" target="_blank">whitepaper</a> providing an overview of their approach to security. It appears to be a good approach and shows that the company is serious about security because security is baked into the iOS cake and not merely included in the icing on its surface.<br />
<br />
<b><span style="font-size: large;">Pros</span></b><br />
<u>Secure boot chain</u> -- Read only LLB is implicity trusted. It loads iBoot after verification which loads iOS after verification. This makes is really difficult to get untrusted code on the device even if an adversary has physical access to the phone. It is still possible if he can mess with the LLB, and I doubt if the hardware has robust resistance to physical tampering, so high value targets should not rely on this.<br />
<br />
<u>No downgrade</u> -- Software downgrades are not allowed, thereby narrowing the window of opportunity for an adversary to exploit a software vulnerability to the time it takes to patch the system. Once patched, the window is completely closed.<br />
<br />
<u>Curation and signed app</u>s -- Every app is reviewed by Apple and digitally signed. However, because of the size of the developer community, Apple cannot possibly check the apps to guarantee lack of malicious code. I still consider this a pro, because it does reduce the vulnerability surface(and until we get some breakthroughs in computer science theory where a program can be proven benign this is the best one can do). A user should understand that he is trusting the app developer and not Apple for 3rd party apps.<br />
<br />
<u>Entitlements</u> -- Every app that requires privileged resources explicitly gets rights to specific resources. This is an implementation of the principle of least privilege and is a better option than implicitly allowing access to everything.<br />
<br />
<u>Erase function</u> -- Contents are erased by erasing keys required to access them. This makes the process quick and hence more likely to be used when needed.<br />
<br />
<u>Random keys in flash DMA engine</u> -- These are not known to the manufacturer or Apple. So there should be no backdoors.<br />
<br />
<span style="font-size: large;">Cons</span><br />
<u>Enterprise app provisioning</u>-- It is not clear how this is handled. Can an enterprise app access personal data of the user? Can the user remove the app when he chooses to?<br />
<br />
<br />
<u>Erase function</u> -- Erasing keys should be followed by actually erasing the file data as well. This will protect against attacks on the ciphertext. Assuming AES is secure is reasonable but assuming that the key generation scheme is perfect is not.<br />
<br />
<u>Reliance on passcodes</u> -- Although there are delays between attempts to thwart a brute force attack, passcodes are not very secure for the average user. An adversary can see the user type the passcode, look at fingerprints on the screen to significantly narrow down the scope of the brute force attack etc.<br />
<br />
[Apple today <a href="http://www.networkworld.com/news/2012/072712-apple-to-spend-356-million-261208.html?hpg1=bn" target="_blank">acquired</a> a biometrics company, so perhaps we will see this issue get addressed in the next iteration of iOS. Hopefully, it will be available to older generation hardware as well.]<br />
<br />
<u>Keychain</u> -- Apple does not allow the user to make the security vs usability tradeoff here. Most keys (like Exchange password) are available in memory after the first unlock of the phone. This allows background apps to run but there should be a way for more security conscious users to opt out of this and have the keys in NSFileProtectionComplete class so that they are erased from cleartext DRAM memory when the phone is locked.<br />
<br />
<u>Incomplete forward secrecy</u> -- There seems to be no way (apart from backing up all data and erasing everything) to re-encrypt files with updated keys. Only the keys used to wrap the file encryption keys are changed. This is a problem in the following scenarios --<br />
1. An adversary gets access to unlocked phone and is able to retrieve the file encryption keys. The user(upon discovering this) changes the passcode thinking that any new data saved in the file will be protected. But, the file is still encrypted with the compromised key and the adversary can decrypt the file by getting access to the device.<br />
2. A bug is found in the key generation scheme. In this case, Apple can avoid writing the re-encryption code until it discover the bug and publishes the patch.<br />
There is a way to re-encrypt files with new keys by backing up all data, erasing everything, choosing a new passcode and restoring from backup.<br />
<br />
<br />
Reference<br />
http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-51892320769700154542011-03-24T18:33:00.000-07:002011-03-24T18:50:32.070-07:00RSA SecureID is now 1.5 factor not 2Everyone is trying to figure out what really happened. One <a href="http://www.networkworld.com/news/2011/032311-rsa-securid-backdoor.html?page=2">theory </a>is that there was a government backdoor. That is possible since SecureID is a closed technology and it is unclear how it works. It has not been reviewed for strength of architecture/algorithm that could cause unintentional security breach or absence of intentional backdoors.<div><br /></div><div>Network World reported the following:</div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Arial, Helvetica, sans-serif; font-size: 14px; line-height: 20px; ">In its "Incident Overview," which was part of the update, RSA stated, "To compromise any RSA SecurID deployment, an attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information."</span></div><div><span class="Apple-style-span" ><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;"><span class="Apple-style-span" style="font-family: Georgia, serif; font-size: 16px; color: rgb(0, 0, 0); line-height: normal; "><br /></span></span></span></div><div>This indicates that an attacker can get access to a protected system without having physical possession of the SecureID token. If that is true, the other RSA quote (from Network World)</div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Arial, Helvetica, sans-serif; font-size: 14px; line-height: 20px; ">Many are, in fact, bewildered by the statement Coviello made on March 17: "While at this time we are confident that the information extracted does not enable a successful direct attack on any of our SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack."</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Arial, Helvetica, sans-serif; font-size: 14px; line-height: 20px; "><br /></span></div><div>would mean that the "reduction in effectiveness" is basically that the authentication is no longer based on two factors. It is based on one factor (and some phishable data) only.</div><div><br /></div><div><b>How is this possible?</b></div><div>I don't know how SecureID works but this is how 2 factor authentication works and it must do something like this:</div><div>One factor is something that you have, in this case, a hardware token. This presumably would have a private key which would be shared by the authentication server (or the server will have a paired public key). Ideally, every token would have a completely random key but RSA may have taken a shortcut and used one that is somehow dependent on the serial number of the token(or some other insecure input like customer id etc). If the attacker was able to get information that can be used to guess this key from the serial number(or other info) then he or she can succeed in authenticating without having access to the token itself.</div><div>This theory is not incompatible with the government backdoor; indeed the government may have asked RSA to use introduce the above weakness. Or it could have figured it out a long time ago on its own.</div><div><br /></div><div><span class="Apple-style-span" ><span class="Apple-style-span" style="font-size: 14px; line-height: 20px; "><br /></span></span></div><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8609860739720977854.post-7245346758098832332010-05-09T00:26:00.001-07:002010-05-09T01:21:50.759-07:00Evolution in the Data CenterOk, this post does not have much to do with security (except for one of the points below). I've been catching up on happenings in the data center these days and it appears a gradual evolution is underway. The following is what I understand and I wrote it down so that<br />- you might avoid having to do the research<br />- more selfishly, you might point out mistakes in my understanding<br /><br />1) What is virtualization -- First of all, the hypervisor has very little to do with what is happening in virtualization now. Until I figured that out (I thought virtualization and hypervisor are one nad the same; and although it is cool to be able to run multiple OS's on a CPU, one can achieve 80-90% of what a hypervisor provides without virtualization) I did not think virtualization was of much use and that is was hyped unnecessarily by the tech media. Now I realize that virtualization is not about the hypervisor (yes, it is now an important element but almost commoditized) but about tools that help IT admins to dynamically respond to changing IT needs such as:<br />- Provisioning new applications quickly<br />- Scaling them up or down to meet changing loads<br />- Migrating them to different servers in the same or a different data center for performance or power optimization or for disaster recovery etc.<br /><br />2) Components of a virtualized data center -- To achieve the above goals the following components are needed:<br />- Servers -- Of course, where else would the applications run :)<br />- IP switches/routers -- For users to access the applications and for applications to talk to each other. If NAS is used these also provide access to storage<br />- Optional storage switches -- Although theoretically possible to use storage attached to servers directly, it is more efficient to use specialized storage like SAN or NAS. If SAN is used, FC and/or FCoE switches are needed.<br />The above components are not new. They have been used in data centers for ages. But virtualization does impose new requirements on them.<br />- Virtualization magic software -- This is a new and hence arguably the most important component. It is the software that allows the IT admin to orchestrate the changes needed to achieve the three goals mentioned in (1) above. This is what made VMWare successful (for a long time I thought it was the hypervisor!). Scalent makes another nice one...I am sure there are others<br /><br />3) Market Dynamics -- This evolution of the data center provides an opportunity for vendors of the above components(incumbent and upstarts) to innovate within those product categories(to address the changing requirements). That will surely happen and within a year or two , I believe, all vendors within those categories will have 90% matching features with remaining 10% in a diminishing returns but unavoidable arms race. On the other hand, this evolution also provides large incumbent vendors an opportunity to innovate across categories providing vertically integrated solutions (like Cisco, VMWare, EMC). Of course, this creates an opportunity for exactly the opposite innovation: enabling standard, interoperable, multi-vendor solutions. Scalent is a good example of this. I think in the end the latter will win but it might still make sense for companies like Cisco to delay this for their products and pursue vertical integration to gain market share.<br /><br />It will be fun to watch this happen!<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8609860739720977854.post-51134834811777655912009-07-16T13:48:00.000-07:002009-07-16T15:12:59.079-07:00Is SSL broken?I was reading <a href="http://www.networkworld.com/news/2009/071609-ssl-vpn-hack.html?page=1">Network World</a> and for a very brief moment was alarmed to learn that SSL is not secure and that Tim Greene recommends (or is he quoting the researchers opinion?) that people should not use public wifi even for SSL-safe browsing.<br /><br /><span style="font-size:85%;">[Network World article says "SSL VPN..." although the threat if real should apply to non-VPN uses of SSL as well and the examples cited are for online banking and most people won't call an SSL connection to their bank an SSL VPN. SSL VPN is the extension on an "intranet" over the internet using SSL to secure it]<br /></span><br />Then I found the <a href="http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1361180,00.html">this article</a> that seems to have slightly more data. I havn't seen the demonstration but I have a suspicion that this is much ado about nothing. It seems the flaw is that if parts of the page are EV SSL and other parts are not EV SSL the browser does not complain <span style="font-weight: bold;">as long as the domain is the same</span>. (The part is bold is my assumption but if it is true, there is nothing to worry about. If my assumption is not true all hell will break loose, public Wifi or not!). I think all parts are not EV SSL because the site owner did not want to shell out extra money for EV SSL certificates for every sub-domain. This makes sense, because EV SSL is <a href="http://www.networkcomputing.com/showArticle.jhtml?articleID=197006006">pretty much useless</a> and I don't understand why the website got an EV SSL certificate at all!<br /><br />If you read this and know that my assumption above is false, please comment and let me know. I should stop using the internet!<br /><br />Update 3.11pm: Found the abstract here: http://www.blackhat.com/html/bh-usa-09/bh-usa-09-speakers.html<br /><br />[scroll down to find "Alexander Sotirov, Mike Zusman<br />Breaking the security myths of Extended Validation SSL Certificates" ]<br /><br />My assumption is valid. SSL is still secure. Their point is that EV SSL is not more secure than cheapo SSL.<br /><br /><span style="font-size:85%;">"Unfortunately, it turns out that the security offered by EV certificates is not any better than the security of even the cheapest $12 SSL certificate</span>"<br /><br />We already know that is true...this is one more reason and makes it "truer", if that is possible :-)<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8609860739720977854.post-55752611363853742652009-07-15T10:50:00.000-07:002009-07-15T11:03:13.200-07:00How safe is your Twitter account?Twitter has been successfully hacked several <a href="http://twitpwn.com/">times </a>but the most egregious of them all is the <a href="http://www.pcworld.com/businesscenter/article/164182/hacker_i_broke_into_twitter.html">breakin </a>that compromised Twitter's own employee and other confidential information. I don't use Twitter but I am concerned about the security of other major social networks like Facebook, Orkut etc; frankly, I don't think they are much better. In the race to capture more and more users social networking websites and applications often ignore security and privacy issues. This is because these issues are considered an economic externality by these companies. In that respect, the information age is a bit like the early industrial era where corporations ignored the impact of their factories on the environment. We need laws that "internalize" these externalities. But given the focus of the government on the economic crisis, health reform and other issues, will this important issue be addressed?<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-17444519863637023002009-04-16T14:24:00.000-07:002009-04-16T14:32:55.292-07:00How secure will the smart grid be?There is a good <a href="http://www.time.com/time/nation/article/0,8599,1891562,00.html?xid=rss-topstories">article</a> about the security of our power grid. Unlike the innumerable fear-mongering writeups I generally find, this one is quite reasonable.<br />In particular I find this paragraph about the increasing proliferation of "smart-grids" interesting:<br /><br /><span style="font-family: courier new;">While Meyerrose, Mansoor and other experts agree that the utility industry's vulnerability will grow as its command-and-control systems rely ever more on computer networks, those concerns are not new. Some security experts have cautioned against the growing use of "smart grid" technology — which relies even more on computer networks to allow both utilities and individual consumers to monitor and reduce power usage. There are already 2 million smart meters in use in the U.S., and the Obama Administration's 2010 budget includes $4.5 billion in spending on such technology. The fear is that these meters may allow hackers access to the grid's control systems.<span style="font-weight: bold;"> But smart-grid backers say the opposite is true: the use of more-sophisticated monitoring systems makes the grid safer.</span></span><br /><br />Of course, they will say this because that is good for their business. The truth is that it depends on the details. If these systems are designed with security in mind they will be safer. If not (and this is more likely), the new smart grid will be less secure than the "dumb" grid we have today.<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-63152034504075803182009-03-24T12:08:00.000-07:002009-03-24T12:27:26.766-07:00Phonefactor: how secure?A system is only as secure as its weakest link. <a href="http://www.phonefactor.com">Phonefactor </a>seeks to replace hardware security tokens <a href="http://www.phonefactor.com/how-it-works/overview/">with your phone</a>. It is an interesting idea because not only does it use two factors: something you know (password) and something you have (phone)but also because it uses two channels: internet and phone (unless of course your phone is VoIP*). This would appear to increase security but it doesn't necessarily do so. The challenge in using a phone in real-time for authentication is that you have to handle the case where the user is not near the registered phone or if it is a cellphone and it is not reachable when the user wants to log into her account. And<a href="http://www.phonefactor.com/how-it-works/faqs/#WhathappensifIlosemyphone"> handling of this case</a> is the weak link. The system has to fall back to what Phonefactor claims "strong security" but which in reality is quite weak. All you have to do in convince the call center staff to do a one time bypass or change the registered phone number. Usually this is done by asking for information like social security numbers, mother's maiden name etc. This is not secure. If it were, why have the phone factor at all? Just ask these questions on the internet while authenticating the user. Indeed, many banks/brokers have adopted this approach(I am not saying that this is secure). But some like one of my credit unions have fallen for the marketing gimmick and false sense of security provided by Phonefactor.<br /><br />*Even if your phone is not VoIP, your provider may be susceptible to being hacked. For now, I ignore that angle, because there is a much easier way to bypass the 2nd factor.<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8609860739720977854.post-2713714099822138622009-01-21T10:03:00.000-08:002009-01-21T17:42:34.962-08:00Signs of intelligent life appear in Washington...still missing from Mumbai<span id="SVsite" style="font-family:courier new;"><span id="SVarticle"><span style="font-family:arial;">There are signs of intelligent life in Washington security circles</span>:<br /><br />A federal appeals court in Philadelphia ruled that would violate the First Amendment, because filtering technologies and other parental control tools are a less restrictive way to protect children from inappropriate content online. </span></span><br />http://www.siliconvalley.com/latestheadlines/ci_11511321?source=email<br /><br />But missing in the Mumbai police department<br /><br /><span style="font-family: courier new;">...several police teams, armed with laptops and internet-enabled mobile phones, will randomly visit homes to detect unprotected networks.</span><br /><span style="font-family: courier new;">http://blog.wired.com/sterling/2009/01/bombay-cops-kee.html</span><br /><br /><br /><span style="font-family:arial;"></span><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-27197566843157388132008-04-25T14:12:00.000-07:002008-04-25T14:31:36.898-07:00Should Microsoft encrypt/obfuscate patches?Securityfocus has this <a href="http://www.securityfocus.com/news/11514">story</a> about a group of researchers that have found a way to semi-automate the creation of exploits.<br /><span style="font-family:courier new;font-size:85%;">... Microsoft </span><a jref="http://www.securityfocus.com/news/8547"><span style="font-family:courier new;font-size:85%;">has not taken adequate steps</span></a><span style="font-family:courier new;font-size:85%;"> to make such attempts more difficult, Brumley said. The researchers suggested possible avenues that Microsoft could pursue to increase the likelihood that customers received patches before attackers could reverse engineer them, including obfuscating the code, encrypting the patches and waiting to distribute the key simultaneously, and using peer-to-peer distribution to push out patches faster.</span><br /><span style="font-family:Courier New;font-size:85%;"></span><br /><span style="font-family:times new roman;">The researchers recommend the above for Microsoft. However, each method may create more problems than it solves. Let us consider them, one by one:</span><br /><span style="font-family:Times New Roman;">1)<strong>Obfuscate the code</strong> - Obfuscating the patching code doesn't help at all. One could simply snapshot the system before and after applying a patch and get the diffs. Obfuscating the application code (the application that is being patched) if done manually will make it prone to more bugs and hence more exploits. Automated obfuscation will not introduce any extra bug/exploits but it could make the application run slower.</span><br /><span style="font-family:Times New Roman;"></span><br /><span style="font-family:Times New Roman;">2)<strong>Encrypt the patches and withhold the key</strong> - Well, the key will have to be distributed eventually. The window of opportunity for automated exploit generators will be smaller assuming the key can be distributed faster than the patch. However, the window of opportunity for zero-day exploits will be bigger. Also, the exploit generation can be done by using as input IDS/IPS signature updates instead of the patch. So should you encrypt those as well and withhold the key?</span><br /><span style="font-family:Times New Roman;"></span><br /><span style="font-family:Times New Roman;">3)<strong>Using peer to peer distribution of patches - </strong>This could work...but why is it better than using other content delivery methods?</span><br /><strong><span style="font-family:Times New Roman;"></span></strong><br /><span style="font-family:Times New Roman;"></span><br /><span style="font-family:Times New Roman;"></span><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-39136013571200032482008-02-15T15:51:00.000-08:002008-02-15T16:39:32.571-08:00Can I protect private data from the threat of coerced password disclosure?<span style="font-family:times new roman;">Bruce Schiener </span><a href="http://http//www.schneier.com/essay-199.html"><span style="font-family:times new roman;">mentioned </span></a><span style="font-family:times new roman;">the threat of government authorities asking you to divulge the password to your encrypted file or disk:</span><br /><br /><span style="font-family:arial;">The latter threat is becoming more real. I have long been worried that someday, at a border crossing, a customs official will open my laptop and ask me to type in my password. Of course I could refuse, but the consequences might be severe -- and permanent. And some countries -- the </span><a href="http://www.schneier.com/blog/archives/2007/10/uk_police_can_n.html"><span style="font-family:arial;">United Kingdom</span></a><span style="font-family:arial;">, Singapore, Malaysia -- have passed laws giving police the authority to demand that you divulge your passwords and encryption keys. </span><br /><br /><span style="font-family:times new roman;">This is indeed a pain. The same could be done by an adversary by holding you at gun-point etc. Truecrypt, a free disk encryption software that I use, has a partial </span><a href="http://www.truecrypt.org/docs/?s=plausible-deniability"><span style="font-family:times new roman;">solution</span></a><span style="font-family:times new roman;">. It allows you to create a hidden volume within an encrypted volume. So to protect yourself from the above threat you can enter the password for the outer volume and deny the existence of any inner volume. I don't know how Truecrypt implements this but I think it works somewhat like this:<br /><br />The descriptor of the inner volume(and not just the user data) is stored at a fixed location and encrypted with the inner volume's password. Until that password is typed there is no way to know whether there is a valid descriptor(and hence a hidden volume) or not.<br /><br />This is nice since one can pretend that the inner volume does not exist and the adversary has no way to prove otherwise(all unused space is initialized with random bytes). However, a clever adversary may threaten to overwrite the fixed location where the hidden volume's descriptor resides. At that point you can choose between disclosing the data to the adversary or losing it forever. And in many cases it is good to have that choice.</span><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-67873946656704808852008-01-15T11:21:00.000-08:002008-01-15T12:03:06.471-08:00To WPA or not to WPA?Renowned security expert Bruce Schneier wrote a controvertial <a href="http://www.schneier.com/blog/archives/2008/01/my_open_wireles.html">essay</a> arguing about the benefits of keeping his home wireless network unsecured. He talks a lot about less important things like the possibility of someone using your network for doing bad stuff and getting you involved in legal proceedings. He is not concerned about it and neither am I.<br /><br />However, as this <a href="http://wifinetnews.com/archives/008126.html">article</a> points out Bruce mentions the most important point only in passing: he has secured his computers in a way that the wireless link being unsecure does not matter to him(perhaps disk encryption and VPN). This is probably because he travels a lot and uses unsecured wireless access often. Many people don't. I don't use any public wireless network. I don't have a reason to use PGP or any other disk encryption techology on my laptop. I do however have a desktop at home which is accessible only from behind my internet firewall and since it is connected only via a wired link I do not have to lock it down (use long and difficult passwords, change passwords often, use disk encryption etc). If I make my wireless network open, drive-by hackers can easily hack into my desktop and laptop. Passive eavesdroppers can read my mail, instant messages etc. easily when I am using my laptop to access them. Choosing between taking that risk and enabling WPA is a no-brainer for me.<br /><br />Regarding WPA Bruce says:<br />"This is not to say that the new wireless security protocol, <a href="http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access">WPA</a>, isn't very good. It is. But there are going to be security flaws in it; there always are."<br />The question is not whether WPA has any flaws or not, it is whether any have been found and are easily exploitable by drive-by hackers. In his own words "security is a tradeoff". As a I mentioned above this tradeoff is a no-brainer to me.<br /><br />The bulk of Bruce's argument centers on social politeness. He has an open network to provide people "stranded without internet access" the courtesy of using his network. If this can be done without jeopardizing my own security I won't mind. However, I am not going to encrypt my disks, use strict password policies etc in order to do that. Bruce already did that for other reasons and "sharing" is easy for him. Good for his neighbors!<br /><br />However, the social politeness argument involves another party: the ISP. This <a href="http://www.networkworld.com/community/node/23714">article</a> does a good job of explaining that factor. Under most ISP's terms of service, sharing your internet connection is analogous to sharing your cable TV: it is illegal. There may be other terms of service where you buy internet access "by the byte or by the hour" and in those cases it is perfectly OK to let others use your connection. However, how many people will continue to extend this courtesy if it cost them by the byte? It is easy to share something that doesn't cost you anything extra. Bruce uses economic reasoning particularly the concept of externality often to explain security issues. That concept applies here: the action of a subscriber to extend his internet access to neighbors and others has a consequence for the ISP. Charging by the byte or by the hour makes this externality "internal".<br /><br />In conclusion, regarding the question of whether to use WPA on your home wireless or not, I find that it really depends on your situation. If your computers are secured and your ISP does not mind, you may decide to extend "internet access courtesy" to those in your wireless range. Otherwise, it is better to secure your wireless connection.<div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-4680626989258119162007-10-15T16:37:00.000-07:002007-10-15T16:43:20.677-07:002factor's RPM: is it secure?Network World just published a list of "<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.networkworld.com/news/2007/101507-top-10-security.html?page=1" target="_blank">10 IT Security Companies to watch".</a><br />The first company <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://2factor.com/secureweb.php" target="_blank">2Factor </a>claims to improve security by provinding a "secure applet" that continuously generates new keys for each transaction. The hypothesis is that "This session of the browser is completely controlled by the SecureWeb® software, eliminating the threat of hacking attacks". The assumption is probably that a new applet will avoid vulnerabilities in the browser and hence will be secure. However, this applet is only as secure as the hardware and OS it is running on. How does this scheme protect against rootkit based Trojans? How difficult is it to "hijack" the icon that it creates? ["Online customers perform a one-time download of a small file that places a bank-branded icon on their computer desktop. "] and replace it with a Trojan that invokes the applet in a sandbox and has access to all its state? How is the process of downloading this applet secured? Until I have answers to these question, I would be wary of this technology.<br />This technology may be useful for improving performance compared to SSL-PKI if it has a equally good way(or better) of generating keys which is faster. However, since crypto-accelerator hardware is so mature these days I doubt if the "performance story" alone would make this startup fly. Maybe the founders felt the same and that is why they cooked up the "security story" I criticized above. 2factor also <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://2factor.com/benefits.php" target="_blank">claims</a> "the advent of quantum computers will render current technology useless, RPM's underdetermined system of equations is PROVABLY secure". I don't think quantum computers are arriving anytime soon, but I would love to know if RPM has been evaluated by cryptographers against the claim of being provably secure.<br />2factor does have an <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://2factor.com/easier.php" target="_blank">"easier story"</a> and that might indeed be a valuable advantage.<br /><br /><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/btn-fave2.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/tech-fav-1.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><br /><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-21749366976843925672007-09-14T13:00:00.000-07:002007-09-17T16:39:16.648-07:00How not to handle data leaks: TD AmeritradeI was greeted this morning by my broker's CEO. After telling me that he leaked my data he added:<br /><em>"Please be assured that UserIDs and passwords are not included in this database, and we can confirm that your assets remain secure at TD AMERITRADE. "</em><br />This is good, but even if they were exposed:<br />- if the passwords were "hashed" with nonces (like they <a href="http://www.securityfocus.com/blogs/262">should be</a>) I have nothing to fear.<br />- if they were stored in cleartext or without nonces and if I had a weak password, I could just go and change it.<br />He continues to say:<br />"You continue to be covered by our <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://clientnews.tdameritrade.com/r/c/r?2.1.Hw.FH.1S0ngO.C5%5f5aK..H.CwKK.28xI.DMDQEWU0" target="_blank">Asset Protection Guarantee</a>..."<br />and that is good because even if the password scheme and password were weak and the crook logged in before I changed my password, I am protected. Awesome! And so far so good, except that I would expect this announcement to being with an apology for leaking my data.<br /><br />But reading further I start to get nervous:<br /><em>"While Social Security Numbers are stored in this particular database, we have <strong>no evidence</strong> to establish that they were retrieved or used to commit identity theft."</em><br />On their FAQ page they say:<br /><em>"After extensive investigations involving outside forensics experts, we have <strong>no evidence that this sensitive personal information was taken</strong>. That is one of the reasons why we have also hired ID Analytics. Its initial investigation has concluded that there is no evidence of identity theft as a result of this issue.Because of our ongoing investigation, we will not provide additional details."</em><br />In another place they say:<br />"<em>In fact, we have been able to <strong>conclude that this sensitive information belonging to our legacy TD Waterhouse retail and institutional clients was not retrieved.</strong>" </em><br />I wonder how they established this and already alienated by the rest of the <a href="http://www.amtd.com/">PR material</a> I am inclined to believe that this is misinformation as well.<br /><br />They use the terms "extensive", "initial", "continuing" to describe their investigation depending on what they are trying to say. They use "initial" and "continuing" when trying to convince me that they cannot tell me how the forensic experts reached the conclusions they did but they use "extensive" when they want to convince me that these conclusions have been reached.<br /><br />TD Ameritrade having no evidence that my sensitive information was leaked or of identity theft does nothing to calm my nerves. The crooks could still have this information. They could have covered their tracks so that there is no evidence. They may have left behind evidence which TD Ameritrade will never find (infact TD Ameritrade has a lot to gain by not finding this evidence and a lot to loose by finding it). They may not have used this information yet knowing the heightened alert level right now. What stops them from using this information later? The legal system is clearly <a href="http://blog.wired.com/27bstroke6/2007/08/federal-court-s.html">not on my side</a> as depicted by this ruling in another data leak case:<br />"Without more than allegations of increased risk of future identity theft, the plaintiffs have not suffered a harm that the law is prepared to remedy."<br />How would I ever be able to tie a future ID theft to TD Ameritrade's leak?<br /><br />Why can TD Ameritrade get away with this? This is because my security is not their concern. It is an <a href="http://www.schneier.com/blog/archives/2007/01/information_sec_1.html">externality </a>for them. The only way to solve this recurring problem is to change that and no advance in security technology can change the law. Meanwhile, not using <a href="http://securetheworld.blogspot.com/2007/01/social-security-numbers-as.html">immutable and leakable information for authentication</a> will help ease some of the pain.<br /><br />Now there is news coverage (Sep 17)<br /><a href="http://www.darkreading.com/document.asp?doc_id=134056">http://www.darkreading.com/document.asp?doc_id=134056</a><br /><a href="http://www.wallstreetandtech.com/blog/archives/2007/09/why_td_ameritra.html">http://www.wallstreetandtech.com/blog/archives/2007/09/why_td_ameritra.html</a><br /><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/btn-fave2.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/tech-fav-1.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><br /><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8609860739720977854.post-30175094220482810772007-08-21T12:04:00.000-07:002007-08-21T12:25:37.343-07:00Another multi-core...<a href="http://www.tilera.com/">Tilera</a> has come out of the closet. There is a good writeup about its 64 core processor <a href="http://arstechnica.com/articles/paedia/cpu/MIT-startup-raises-multicore-bar-with-new-64-core-CPU.ars/1">here</a><br /><br />Here is a snippet from the article:<br />"what will make or break Tilera is not how many peak theoretical operations per second it's capable of (Tilera claims 192 billion 32-bit ops/sec), nor how energy-efficient its mesh network is, but how easy it is for programmers to extract performance from the device."<br /><br />I agree. And by focusing on the development environment, ability to run SMP Linux etc, Tilera has chosen to offer a smooth learning curve to software engineers. Although there are some design wins, it remains to be seen whether taking the first few steps on this curve offer a significant advantage over the wares sold by Tilera's competitors: Intel, AMD, Cavium, RMI and Sun.<br /><br />There is another good article <a href="http://www.tgdaily.com/content/view/33451/135/">here</a>. An interesting point about pricing:<br />"For a new entry into the market, Tilera priced its product with confidence: 10K-tray pricing is set at $435 for each Tile64 – which appears cheap, if it can replace ten Xeon processors. But in a real world environment, the processor is priced against a quad-core Xeon 5345 (2.33 GHz, 8 MB L2 cache), which currently sells for a 1K tray price of $455. "<br /><br /><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/btn-fave2.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/tech-fav-1.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><br /><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-76506113033203411912007-08-07T09:23:00.000-07:002007-08-07T09:58:39.409-07:00Chief blogging officers debating NAC"Chief Blogging Officers" at two security vendors have a highly technical and meaningful debate:<br /><br /><a href="http://www.nevis-blog.com/2007/08/wondernac-i-lik.html">http://www.nevis-blog.com/2007/08/wondernac-i-lik.html</a><br /><a href="http://www.stillsecureafteralltheseyears.com/ashimmy/2007/08/more-on-the-won.html">http://www.stillsecureafteralltheseyears.com/ashimmy/2007/08/more-on-the-won.html</a><br /><br /><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/btn-fave2.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/tech-fav-1.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-27809591552939008492007-07-20T11:21:00.000-07:002007-07-20T11:31:53.339-07:00Privacy@GoogleWhile responding to concerns about privacy of those who use Google's services Eric Schmidt said that users worried about privacy can choose not to use Google's services. Not only does this response reflect sheer hubris on his part and alienate intelligent beings, it also sidesteps the real question "Should users of Google be worried about privacy?". Privacy international says YES.<br /><br />Privacy international findings are here: <a href="http://www.privacyinternational.org/issues/internet/interimrankings.pdf">http://www.privacyinternational.org/issues/internet/interimrankings.pdf</a><br /><br /><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/btn-fave2.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/tech-fav-1.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-32231200991213832842007-07-07T20:37:00.000-07:002007-07-07T21:09:48.974-07:00security research, rootkits and TPMThe recent highlight on security research has encouraged a lot of "security researchers" (although the term is a bit too generic...these people are actually "vulnerability researchers"). Today's software contains a lot of security bugs and these researchers find a lot of them. It is a good thing...it helps raise awareness of the problem and pushes the software vendors to fix these bugs.<br />The media limelight on these researchers also encourages "publicity stunts" and other "celebrity wars". Here is an example:<br /><a href="http://www.securityfocus.com/brief/537">http://www.securityfocus.com/brief/537</a><br /><a href="http://www.matasano.com/log/895/joanna-we-can-detect-bluepill-let-us-prove-it/">http://www.matasano.com/log/895/joanna-we-can-detect-bluepill-let-us-prove-it/</a><br /><br />I do believe that "theoretically" it is impossible to write an undetectable rootkit if the detection system is allowed access to the external world (network access is usually good enough). However, "practically" it is a contest between the rootkit engineer and the rootkit detector engineer. It is certainly possible although difficult to create a rootkit that will be very hard to detect. Similarly, it is possible but difficult to engineer a rootkit detector good enough to detect this rootkit.<br /><br />Trusted Platform Module is a promising technology that might render the issue moot in the long run. However, TPM itself may have bugs in the beginning: <a href="http://www.networkworld.com/news/2007/062707-black-hat.html">http://www.networkworld.com/news/2007/062707-black-hat.html</a><br />I don't know why these guys withdrew...was it because they had found no exploits or were silenced by the TCG?<br /><br />TPM may have some vulnerabilities in its specification and implementations of the specification will certainly have more. It is still a good technology because in a world with TPM bugs will be confined to a small area and therefore could be more easily found and fixed than in a world without TPM.<br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/btn-fave2.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/tech-fav-1.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8609860739720977854.post-91316046604064706812007-04-24T10:03:00.000-07:002007-04-24T10:36:51.906-07:00What is a Host IPS?The term Host IPS is used mostly to denote endpoint software that monitors execution of applications and looks for intrusions. Interestingly, the term Host IPS implies the absence of signatures whereas the term network IPS generally implies the presence of them :) Of course, Host IPS is generally supposed to complement signature based anti-virus and contemporary network IPS's utilize <a href="http://securetheworld.blogspot.com/2007/01/ips-algorithms.html">more techniques</a> in addition to signatures.<br /><br />Most host IPS's use a mix of the following techniques to monitor program execution (sometimes called program "behavior"):<br />- intercept system calls<br />- intercept access to resources like registry, file system, libraries(DLLs)<br />- track origin of the code being executed<br />- execute the program in a sandbox...the extreme case is interpreting the program instruction by instruction instead of running it directly on the processor.<br /><br />There are several compile time tools for making the stack difficult to overflow. These defend(not foolproof) against buffer overflows on a stack:<br />- <a href="http://www.ece.cmu.edu/~adrian/630-f04/readings/cowan-vulnerability.pdf">stack guard</a><br />- <a href="http://www.angelfire.com/sk/stackshield/">stack shield </a><br />- stack ghost<br /><br />...and a run time method<br />- <a href="http://www.cag.lcs.mit.edu/rio/security-usenix.pdf">program shepherding</a><br /><br />Some commercially available Host IPS products are:<br />- <a href="//http://www.mcafee.com/us/enterprise/products/host_intrusion_prevention/index.html">McFee</a><br />- <a href="http://www.cisco.com/en/US/products/sw/secursw/ps5057/index.html">Cisco </a><br />- <a href="http://www.symantec.com/enterprise/products/overview.jsp?pcid=1322&pvid=1303_1">Symantec </a><br />- <a href="http://www.determina.com">Determina</a><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/btn-fave2.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/tech-fav-1.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-34748714973930983512007-03-14T12:02:00.000-07:002007-03-25T16:14:21.915-07:00Methods for network based devices implementing data leak preventionI wrote about data leaks <a href="http://securetheworld.blogspot.com/2007/02/personal-information-leaks.html">before </a>. A painful problem like this is an opportunity for some and we now have quite a few startups selling products to monitor data leaving a company's network for sensitive information. <a href="http://www.vontu.com">Vontu </a>and <a href="http://www.reconnex.net">Reconnex </a>are a couple of them. <a href="http://www.portauthoritytech.com/">Port Authority </a>was another that was acquired by WebSense.<br />It is interesting to see how one can go about solving this problem. [Note: In this writeup I focus only on detecting leaks through the company's network. There is another ways in which information can be leaked: through storage devices like hard disks and USB flash. The techniques I mention here do not work for them.]<br />First we need to define sensitive data. A few items like social security numbers can be easily defined as regular expressions (ddd-dd-dddd, where d is a digit) and one can scan all network data for anything that looks like a social security number. But what about other information? We can apply the pattern matching approach to other structured information like patient records in a healthcare facility, account information in a bank etc. What about unstructured information like design documents or patent ideas communicated between team members in emails? It does not follow a pre-defined pattern. Is there a way of monitoring it? Fortunately, there is. One method is to use<a href="http://en.wikipedia.org/wiki/Rabin_fingerprint"> rabin fingerprints </a>. Calculate these fingerprints for all potentially sensitive data and match it with the fingerprints calculated for network traffic. This method works well because even if the data was changed a little (like a section from a document was copy-pasted into an email etc) it is matched by the fingerprints.<br />An approach that combines pattern matching for known and/or structured data and fingerprinting for unstructured data works well in detecting unintended accidental data leaks in information passing through a company's network. A <a href="http://www.networkworld.com/news/2007/031307-data-breach-companies.html">report </a>says that 60% of the leaks reported so far are of this nature. So it is a useful approach. What about the other 40% intentional data theft? I will write about it another day but the first thing that will come into mind is to apply some kind of "locks" and "alarms". Locks in the digital world are cryptographic techniques and alarms are data access, modification and transmission logs.<br /><br />[Some readers will note that I did not mention "watermarks". I consider that as a subset of structured data]<br /><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/btn-fave2.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img alt="Add to Technorati Favorites" src="http://static.technorati.com/pix/fave/tech-fav-1.png" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-5118814407956856582007-03-13T11:51:00.000-07:002007-03-13T14:58:42.659-07:00Sandboxes for false positives in IDSSignatures have been an effective but not exhaustive method for threat prevention for a long time. In the early days there were issues with false postives, then there were shortcomings in dealing with polymorphic threats but these were due to "bad signatures" and sometimes performance tradeoffs. That is no longer true [I <a href="http://securetheworld.blogspot.com/2007/01/ips-algorithms.html">wrote</a> about various IDS algorithms before]<br />However, as I said it is not an exhaustive method so it is often complemented by protocol anomaly detection and behavioral anomaly detection. Protocol anomaly detection(PAD) is a very reliable technique but a mere presence of an anomaly does not always indicate an intrusion. Behavioral anomaly detection(NBAD) is worse because it relies on unproven statistical models of network traffic and user behaviour. [Related <a href="http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf">reading </a>]. However, both of these methods are useful in locating "suspicious activity", protocol anomaly detection more so than behavioral. The challenge is to deal with the false positives they inevitably result in. A good solution to this problem is now available in atleast two commercial products: <a href="http://www.fireeye.com">FireEye </a>and CheckPoint's <a href="http://www.checkpoint.com/products/technologies/mcp.html">MCP </a>which use "sandbox execution" of code extracted from anomalous traffic. The approach is in its infancy but is very promising because it is to intrusion detection what "blood tests"are to disease diagnosis. It has very low false positives and works against zero day threats. It is "expensive" because it requires a lot of computation if PAD and NBAD are used to narrow the search space of traffic, it can scale well.<br />I believe most commercial IDS/IPS and even anti-virus/spyware vendors will add this weapon to their arsenal this year. Thoughts?<br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img src="http://static.technorati.com/pix/fave/btn-fave2.png" alt="Add to Technorati Favorites" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img src="http://static.technorati.com/pix/fave/tech-fav-1.png" alt="Add to Technorati Favorites" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8609860739720977854.post-26130529988632869942007-02-12T17:57:00.000-08:002007-03-13T15:01:36.952-07:00Personal information leaks...I came across this news item <a href="http://news.yahoo.com/s/ap/20070213/ap_on_re_us/security_breach;_ylt=AmTRfUWSmPQsOMV3KG7fmoAEtbAF">http://news.yahoo.com/s/ap/20070213/ap_on_re_us/security_breach;_ylt=AmTRfUWSmPQsOMV3KG7fmoAEtbAF</a><br />about VA losing data again, not reporting it quickly and making a completely useless but misleading remark while doing so: "...it doesn't have any reason to believe anyone has misused data...The agency offered a year of free credit monitoring to anyone whose information is compromised". Useless because if the information was misused VA won't be the first to know and if they did eventually learn that the information is misused they may take another 3 weeks to report it. Perhaps the motivation behind an announcement like this is that it may deter the miscreants from mischief for a year. The other comtemporary data leak (TJ Maxx) has shown that this is not true.<br />Misleading because they are offering 1 year free credit reporting which may give a false sense of security to those customers who use that service. Armed with the SSN and other sensitive information the miscreants can carry out their ill intents after a year. Also some of the mischief they do may not get into the credit report at all and the part which does will take a while before it does show up and at that time it might be too late (e.g. money is transferred to Bahamas etc. and nothing can be done now)<br /><br />I have blogged about the problems of using SSNs and other "permanent" and personal information for authentication here <a href="http://securetheworld.blogspot.com/2007/01/social-security-numbers-as.html">http://securetheworld.blogspot.com/2007/01/social-security-numbers-as.html</a><br /><br /><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img src="http://static.technorati.com/pix/fave/btn-fave2.png" alt="Add to Technorati Favorites" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img src="http://static.technorati.com/pix/fave/tech-fav-1.png" alt="Add to Technorati Favorites" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8609860739720977854.post-9334722403300756032007-02-08T10:55:00.000-08:002007-03-13T15:02:10.885-07:00Microsoft's trusted ecosystem vision and its review at Dark Reading...One of the technologies Bill Gates mentioned as part of Microsoft’s “trust ecosystem” was IPSec. [http://www.microsoft.com/presspass/exec/billg/speeches/2006/02-14RSA06.mspx ]. Tim Wilson at Dark Reading believes that it is an unproven technology ;) and SSL is better. I would like to point out to him that IPSec has been around for a very long time and there are hundreds of good products around. The only reason why SSL became more popular as a VPN method in recent years is because web browsers have it builtin and a lot of applications people were interested in were web based. If Microsoft had provided an easy to use IPSec client in Windows from the beginning it could have been different. As far as core technology is concerned there is both IPSec and SSL use pretty much the same cryptographic algorithms and therefore are equally secure. Since it runs at the network layer IPSec can support almost all applications while SSL is restricted to those that use TCP. While that covers a lot of applications, it does not cover VoIP which uses UDP. In addition IPSec scales well as it does not require the device to terminate TCP. It allows multiple sessions on a single channel resulting in better scalability in terms of the number of concurrent channels a VPN terminating device has to support and the number of key exchanges that need to be done.<br />Tim claims that IPSec is insecure because it connects the endpoint to the whole network whereas SSL connects it to only a specific application. While there is some truth to this, IPSec VPN devices generally allow policies to be configured that can restrict access to specific applications.<br />One of the new frontiers in the security war is the internal corporate network. To secure them one of the things that need to be done is to authenticate endpoints connecting to it and enforce policies. This is being done by NAC (pre and post admission) but the authentication aspect is insecure today because in the absence of a cryptographically secured connection, endpoints can spoof their addresses and fool the NAC devices. I believe IPSec holds promise as a standard and proven technology to fix this problem. I am glad that Microsoft is thinking about this and if they integrate IPSec with 802.1x into Windows seamlessly, it will encourage switch vendors to add IPSec termination to switches and secure the corporate LAN.<br /><br /><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img src="http://static.technorati.com/pix/fave/btn-fave2.png" alt="Add to Technorati Favorites" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com"><img src="http://static.technorati.com/pix/fave/tech-fav-1.png" alt="Add to Technorati Favorites" /></a><br /><a href="http://technorati.com/faves?sub=addfavbtn&add=http://securetheworld.blogspot.com">Add to Technorati Favorites</a><br /><script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script><div class="blogger-post-footer">Securing the world...one computer at a time</div>Unknownnoreply@blogger.com4