HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Displaying articles for: October 2011

You don't know where that's been!

Leaving work recently I saw something shiny in the bushes and quickly discovered that somebody had either lost or discarded a CD in there. My first thought, of course...wonder what's on it (iTunes ain't cheap). Ten years ago, I'm sure I would have found out. Luckily, I now work in the security industry, and know better (most of the time, anyway). Unfortunatly, a lot of people who should don't. I was reminded of the results from a penetration test the Department of Homeland Security conducted this past summer where they dropped thumb drives in the parking lots of various federal agencies. How many were plugged in?  A not insubstantial 60%.  When a corporate logo was included, that rate went up to a staggering 90%. Remember, these are federal employees who one would assume have somewhat regular cyber security training. If HP conducts it once a year, I have to think the government does something similar.


We've been talking a lot amongst ourselves about the RSA breach earlier this year and how it could have been prevented. There are a lot of products and services that HP offers that could have stopped the explotation in its tracks. Unfortunately, we don't yet offer one that can conquer curiousity. In this day and age, when one vulnerability is all it can take to comprimise a site, and when critical infrastructure and information suddenly are web-accessible when that was not the original design, stronger training mechanisms are needed to prevent social engineering attacks of this nature. Are we really that far off from seeing public service announcements about cyber security? Probably not. I think we're about to find out what the cyber equivalent of 'duck and cover' is.

Data Privacy: The United Kingdom Cares, for 500,000 Excellent Reasons

Who is watching the data privacy till?


For the United States, the answer is easy: No one, at least no one with any teeth.


Old Guy Rant


Speaking of toothless, I'll take me a few sentences to vent my wizened spleen.


There is no overarching US disclosure law, which is part of the problem. 46 states have laws. They vary widely in prescriptions directives. Massachusetts, whose data breach standards are high for the US, advises that organizations "shall provide notice, as soon as practicable and without unreasonable delay" when personal data is compromised. Louisiana, which appears much laxer, allows for delay if law enforcement is investigating:  "If a law enforcement agency determines that the notification required under this Section would impede a criminal investigation, such notification may be delayed until such law enforcement agency determines that the notification will no longer compromise such investigation." Sigh.


Still, at from a data privacy perspective,it's much better to live in Louisiana than in Alabama, Kentucky, New Mexico, or South Dakota - which have no such regulation at all.


The bottom line is that, among developed nations, ONLY THE US AND TURKEY LACK NATIONAL DATA PRIVACY LAWS.


You kids get off my lawn.


Case Study: Me

Over the past several years, I have been informed by a bank, a university, and two credit card companies that my personal data had been endangered or exposed through organizational negligence of some sort. The disclosures - proffered grudgingly by US organizations - lagged the actual event by many months. In these disclosures, I received little contextual data to allow me to assess the seriousness of the exposure, so I was left with micro-monitoring my personal identity and financial accounts for significant periods.


Having been through several frustrating experiences with low value disclosures about potentially catastrophic breaches, I am hopelessly jaded about organizational practices around breach disclosures. I fully expected that - some day, soon - I  would fall victim to a breach that compromised my identity, drained my checking account, or both.


On October 24th I received an email, the sort of email I've come to dread, entitled "Apologies from The Register". I subscribe to http://www.theregister.co.uk/security/ , as it's a good place to get cheekily-written security news. After determining it was not a phishing attempt, I read the communication, which follows:




This morning the name and email address you used to register for The Register was mistakenly sent to 3,521 individuals, also readers of The Register.


We've contacted them asking them to delete the email and respect your privacy.


We are of course terribly sorry for this error and have reported ourselves to the ICO. Our initial statement is here:




You are free to edit or delete your account details here:




If you have any questions or would just like to rant at us please send emails to mailto:data@theregister.co.uk



Best Regards

The Register



After working through my "5 Stages of Grief" regarding the loss of my privacy, I realized that The Register should be lauded: I had never witnessed such a quick, appropriate response to a breach, self-instigated or not. This notification was unnaturally forthright, timely, and self-deprecating. The Register was voluntarily taking the fall.


There Must Be More to This Story....

So, of course, I was forced to investigate WHY they were being such good interweb citizens, even posting about it prominently in their own onsite newsfeed. What I found speaks to the efficacy of data privacy regulations with teeth.


Just 4 days before, on October 20th, the UK's  Information Commissioner’s Office (ICO), had announced that is was going to enforce fines of up to 500,000 pounds against organizations that disclose inappropriate personal data. Apparently, the 2010 Lush incident, to which the breached UK cosmetics retailer responded brilliantly, provided a best. practices model for the ICO to regulate around.


The Register followed the Lush model closely in its breach disclosure. This is a wonderful thing. But its decision was inspired at least in part by the Co's strong regulatory presence, and its decision to attach consequences to shoddy security practices that expose private data.


Regulations with teeth encourage compliance. As a nation, the United States must grow a set.

How Much Responsibility Should Developers Have For Security?


One debate that remains incandescent in the security world is the question of how much developers should be held accountable for security. Dinis Cruz did a presentation at OWASP recently on why security should be invisible to developers.


His basic argument is that security is for security people and building things is for people who build things. He says that security people should stop rubbing developers’ noses in their problems and make security transparent so developers don’t need to think about it.


This is mostly a horrible idea.


The easiest way to see this is to take the concept of “building” to any other domain. Quite simply, anyone who “builds” something needs to be responsible for its security. Whether it’s a skyscraper or an automobile, the excuse of “You didn’t give me secure stuff to build with so I made a death trap.” isn’t a strong defense.


It’s true that there are different types of people who “build” buildings. There are those who design them and then there are those who put drywall in and nail up plywood. Perhaps the argument is that people who do basic construction shouldn’t have to know how to build a structurally sound skyscraper.


I could grant that, but it doesn't mean that all builders are unaccountable. Someone on the team creating that structure has to confirm to the earthquake codes, the fire codes, etc. There is a person who's reputation is on the line if they erect a structure that has safety issues.


So, if we’re saying hammer and nails construction people are like entry-level developers who don’t need to know the ins and outs of security, then I ask you who the architect is. Remember that you can’t just send a bunch of hammer and nail guys in to build a skyscraper — you need an architect to lay out an approved plan.


That architect has his license and reputation at risk, and that’s the piece that we’re missing in software. Saying that "developers" don't need to understand security is just wrong. Coders need to be identified as one of two types: hammer and nails types, or design/architecture types. If they’re hammer and nails guys then they shouldn’t be allowed to code without the supervision and review of who is able to put her name on the line.


The one thing that’s completely out of the question is the notion of separating "building" from "security" altogether. It’s not true anywhere else, and it shouldn’t be true for software. You cannot claim to be a "good" developer if you create things you don't understand -- especially when those elements that are nebulous to you have security/safety implications.

If the earthquake certification engineers ask an architect how his building will withstand a 7.0 earthquake on the 19th floor, his answer better not be, "Yeah, I just deal with the stacking of the floors on top of each other -- not so much the making sure they don't fall down."


Security is now part of the process, and it will only become more so as time goes on. If Dinis's only argument was to say we as an industry should make it *easier* for developers to be good at understanding the security of their applications, then I agree wholeheartedly. But he didn't make that argument. Instead he essentially said that they shouldn't be troubled with the issue at all because they're doing the privileged work of building. He wants a clear distinction there, and that's where the mistake was made.


Building something is inexorably tied to securing it. This is true whether we're talking about castles, baby strollers, automobiles, or software applications. Developers don’t get a pass. Building things is hard precisely because there are so many considerations. If a developer doesn't understand how to build securely there's only one proper name for him: a junior developer. ::

Top 10 Web Application Vulnerabilities September 2011

1) PHP 'is_a()' Function Remote File Include Vulnerability


PHP is susceptible to a Remote File Include vulnerability. An attacker can potentially leverage this vulnerability to compromise PHP applications that rely on the vulnerable function or the underlying system itself. Updates which resolve this vulnerability are available. Contact the vendor for additional information.




2) SAP WebAS Malicious SAP Shortcut Generation Remote Command Injection Vulnerability


SAP WebAS is susceptible to a Remote Command Injection vulnerability. An attacker can exploit this vulnerability to inject arbitrary commands into the application and control the generation of SAP shortcuts.  As of this writing no vendor-supplied fixes have yet been made available. Contact the vendor for more details.




3) Novell GroupWise Internet Agent HTTP Interface Stack Buffer Overflow Vulnerability


Novell GroupWise Internet Agent is susceptible to a stack-based Buffer Overflow vulnerability due to a failure of the application to properly sanitize user-supplied data. An attacker can leverage this vulnerability  to execute arbitrary code in the context of the application. Failed attempts will likely result in a Denial-of-Service condition. Updates which resolve this vulnerability are available. Contact the vendor for more details.




4) Adobe ColdFusion Multiple Cross-Site Scripting Vulnerabilities


Adobe ColdFusion is susceptible to multiple instances of Cross-Site Scripting. If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems.  As of this writing no vendor-supplied fixes have yet been made available. Contact the vendor for more details.




5) IBM WebSphere Application Server Cross-Site Request Forgery Vulnerability


IBM WebSphere Application Server is susceptible to a Cross-Site Request Forgery vulnerability. Cross-Site Request Forgery relies on a browser to retrieve and execute an attack. It includes a link or script in a page that connects to a site that the user may have recently used. The script then conducts seemingly authorized yet malicious actions on the user’s behalf.  Fixes for this issue are available.  Contact the vendor for further details.




6) Microsoft SharePoint  Cross-Site Scripting Vulnerability


Microsoft SharePoint is susceptible to a Cross-Site Scripting vulnerability. Cross-Site Scripting can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials. Updates which resolve this vulnerability are available. Contact the vendor for additional information.




7) SAP Crystal Report Server 2008 'pubDBLogon.jsp' Cross-Site Scripting Vulnerability


SAP Crystal Report Server is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage Cross-Site Scripting to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. Updates which resolve this vulnerability are available. Contact the vendor for more information.




8) IBM Lotus Domino 'PanelIcon' Parameter Cross-Site Scripting Vulnerability


IBM Lotus Domino is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage Cross-Site Scripting to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks.  As of this writing no vendor-supplied fixes had yet been made available. Contact the vendor for further details.




9) SAP Web Application Server WEBRFC ICF Service Cross-Site Scripting Vulnerability


SAP Web Application Server is susceptible to a Cross-Site Scripting vulnerability. Arbitrary script code can be executed in context of the affected site in the browsers of unsuspecting users if this vulnerability is successfully exploited. Updates which resolve this vulnerability are available. Contact the vendor additional details.




10) Novell GroupWise 8 WebAccess 'Directory.Item' Parameters Cross-Site Scripting Vulnerabilities


Novell GroupWise 8 WebAccess is susceptible to a Cross-Site Scripting vulnerability.  Cross-Site Scripting can give an attacker  the means to execute arbitrary script code in the browsers of unsuspecting users and steal authentication credentials. Fixes that resolve this vulnerability are available. Contact the vendor for more information.



Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.