by Jay on August 15, 2010
Recently I was tweeting away, and I noticed a comment
@******** See, security should be taught in CS101. It not an immediate fix, but imagine how much better things would be in 10 or 15 years.
I thought to myself: “isn’t basic baked-in security an essential practice – not only for the sake of security, but for general functionality?”. Then I went back to my college days, or what I could remember of them; secure coding was part of the curriculum. In my intro-level programming class, we were taught to trust nothing – be it an automated feed or manual user input. If an input field was not populated using the proper format, our code was to catch it, and to throw an exception. This was taught as a measure to ensure that, if the code was part of a “bigger picture” application, there could be quick resolution in the event of an application failure. However, this basic functionality was also basic SECURITY. Now, it was not detailed in my curriculum that the impact of excluding this functionality may result in “arbitrary code execution” or “unauthorized access to confidential resources” – however, it was clarified that such coded shortcomings could lead to functionality issues. Perhaps if security issues were clarified, we may see better-rounded developers in the future. I seriously doubt it, however…functionality is frequently ranked by developers as being more significant than security.
But wait! At this point, a good deal of developers are NOT college-educated, and would NOT have this formal educational background. I could spend days preaching on about how corporations should favor formally-educated individuals when hiring, or about how they should educate employees on their own, but that’s not the real issue. Every day, I see exploit PoCs written by folks who may or may not have a formal education (trust me, many do not). Good developers and programmers know functional code, and how to render it. The true challenge is separating the good coders from the not-so good…and from the apathetic “this is just my day job” type. This may be integrated in employee rating systems by use of an application security audit regimen at the discretion of the employer.
As far as the mechanisms by which this is accomplished, I shall forever continue to press mandatory code audit, with proper (read: secure, effective, and available) functionality in mind. Every code object should be tracked from declaration to destruction, and both manual (code audit, QA, etc) and automated methods (fuzzers, vulnerability scanning tools, etc) should be used to test the code for errors. If you’ve not got the time to do it right the first time, what makes you think you’ll have the time to do it right when it gets compromised?
Good code is always secure code; secure code is sometimes good code.
</rant>
My twitter feed can be browsed to via this link:
http://twitter.com/_jBlog_
Recently Verizon, in collaboration with the United States Secret Service, released their 2010 Data Breach Report. I would like to take a moment to share my praise, concerns, and general findings.
I’ll begin with business practice findings. In the past, it was emphasized that there was a gap in termination procedures as pertains to access removal from network assets. Based upon the metrics brought forth from this report (an astounding 26% increase in breaches attributed to “insider” threats), this is still a persistent issue. Here, another concern arises when one mentions the concept of segregation of duties; often trusted “insiders” have unhindered or UNDERhindered access to a broad pool of resources. As corporations fail to recognize this, and respectively provide resource access controls and limitations, this will continue to be an issue. Interestingly enough, the percentage of breaches implicating business partners has dropped by 23%. One may attribute this to the increased business awareness and legal controls implemented in the contract phase over the past year. If this trend continues (which it should, as the public is more aware than ever of the threats “in the wild”), this number should continue to drop at a decreasing rate. Additionally, the report indicates that a vast 48% (26% increase) of breaches discovered over the past reporting period involved privilege misuse to some extent – while only 40% of breaches involved “hacking” proper (-24%). This continues to make it obvious that nefarious users do not necessarily have to be “hackers,” and may employ conventional information gathering tactics to procure sensitive data. This may be attributed to the presence of the inevitable “human layer,” and can only be mitigated through a strong, broad-scale, employee education policy. If the point is still unclear, it was reported that 28% (a sizable increase since 2009) of breaches made use of social engineering tactics at some point. While a corporation may have the most “locked-down” and “secure” internet presence, it remains possible that a loose-lipped employee may still unknowingly play a role in facilitating a data breach.
On a rather interesting (read: disturbing) note, 79% of reported victims that were subject to the Payment Card Industry Data Security Standard (PCI-DSS) had NOT achieved compliance. 86% of breaches were preventable via use of reasonable, simple-to-intermediate controls. While PCI may only provide a baseline data security model, following the standard ensures that basic defense mechanisms are in place – and, if a breach happens, the standard assures that the incident will at least be tracked to some extent. On a somewhat related note, 86% of breach victims had substantial evidence logged, yet 61% of breaches were reported by a third party. This indicates to me that log correlation/SIEM tools are not in place (or underreferenced) in many scenarios; avoid becoming a victim by implementing a strong log reference policy. The burden of sorting through can be eased significantly by use of common string parsing tools. Some examples of commercial-grade log/event correlation and management tool vendors include LogLogic, ArcSight, and Q1 Labs. By the way, PCI 10.6 mandates log maintenance.
As far as demographics are concerned, the report continues to indicate that the focus of data breaches remains within the Financial Services, Hospitality, and Retail sectors. This does not surprise me, and should not surprise anybody; Cash is King. Note, however, that this may be attributed in part to the fact that – in the United States (the primary source for the data contained within this report), these sectors are required to adhere to strict breach reporting requirements (due to such regulatory standards as PCI and HIPAA).
On a closing note, the report indicates that approximately 13% of the reported breach cases involved organizations that had recently been involved in a merger or acquisition (as opposed to 9% in 2009). This indicates the all-too-obvious truth that, in the common flurry associated with large-scale corporate policy changes, security assurance is frequently sacrificed. Based upon reading this report, I believe that – in a world where cyber crime continues to be on the rise – large companies need to take a moment to smell the coffee. Making small sacrifices in project deadlines and procuring additional software resources (e.g. log correlation tools, which are essential for far more than just security) to ensure their bottom lines are not only met, but exceeded, while maintaining brand stability.
The 2010 report may be found here
Verizon’s 2009 report (not collaborated with USSS) may be found here
The original blog can be found here
Just dropped 200 bucks on your new webcam (link will be opened in new window) you can use to check up on your pets from across the world? Does it do everything you hoped it would?
News flash – depending upon how it’s configured, it could be doing even more; that same page you browse to in order to check up on Fido may be indexed by search engines such as Google.
Now, 9 times out of 10, the web server is configured to host the content under a non-intuitive URL; while this may deter somebody who is trying to guess the URL used by the software, it also provides those “in the know” with a “one-stop shop” for all of their nefarious needs. As an example, most Panasonic networked cameras have the string “ViewerFrame?Mode=” in the URL, and can easily be located by using the Google search string inurl:”ViewerFrame?Mode=”. If you’re following along with the links, I’m guessing (without actually accessing this page which was likely intended to be private) the third page on the above Google search (it’s a *.edu) is exactly what a hacker would want to see — and exactly what you don’t want them to see**.
To avoid this, it may be possible (depending upon the software) to at least change the default URL used. If not, consult the support documentation – and if necessary, the vendor – to determine the best course of action by which you can better protect your privacy. Depending upon the software leveraged by the device, you may also be able to create a robots.txt file (file including all pages not to be indexed by the search engine) for the web server as well. For more detail, see here.
By the way, it’s not just cameras, but printers and telecommunications equipment (read: WOW) as well. A surprisingly vast listing of known devices (and information on their default pages) can be found here.
** The posted information is for educational purposes only, I neither recommend nor condone using the web as a tool for spying on others. Don’t do it.