TJX finds self at bottom of 300-bank pig pile | The Register
I'm not usually a great fan of the sue someone every time something goes wrong mentality that some people and companies seem to have but this one could actually be good for security...
300 Banks suing TJX for the breach... If they win then I'd expect retailers to start taking security a fair bit more seriously as then there'll be some really serious consequences to losing control of your customers data...
I've always found that there's a fair amount of confusion on what the difference between Information Security and IT Security is.
Whilst I don't know THE difference here's a difference.
IT Security is hard to comprehend but easy to implement, Information Security is easy to comprehend but hard to implement.
If you think about an IT task, say advising on the protection of a new web services link that your company will be sending information over from an IT Security and Information Security perspective the difference in comprehension may become clear.
From an IT Security perspective effectively advising on this requires that you understand how web services function, are aware of the standards in the area (which is complex in itself) understand how XML can be encrypted, what options there are for authentication the transfer and so on. Now once you've comprehended that fully, actually implementing the appropriate protection should be relatively straightforward.
From an Information Security perspective all you really need to know is that web services are a means of transferring data from one party to another, and at that point all you may really care about is "is the information over the link appropriately protected and are participants in the link authenticated and authorised"
So where does the hard to implement bit come in?
Consider a typical Information Security task. Many security standards have a concept that Information in a company should be classified at different levels and then handled differently based on those levels. A typical classification scheme might have 3 or 4 different levels of marking and protection.
In terms of comprehending why you need to do it and even what needs to be done (marking requirements etc.) reasonably straightforward. However implementing this kind of scheme is something that very few corporations have done effectively. The difficulties in training staff, and getting buy-in to what is additional work, from senior management are very tricky to do effectively...
Information Security Sell Out: White Hats & Application Security
Interesting post on the Information Security Sell out blog which comments on story from CNet here and a post over a StillSecure here
I'm mainly with the sellout guy. Whilst it's a shame that we lose an aspect of bug finding, there's no way for a company who see malicious traffic to tell what the intent of the person generating it is and the defence of "I was researching their web site security your honour" doesn't and shouldn't work.
All that said there is a problem and here it is. with the current climate if I find a security vulnerability in a site through legitimate traffic I probably won't report it because I don't want to deal with the possibility that the site owner will take it the wrong way and accuse me of hacking.
Here's an example. I clicked on a link to a site from a forum I hang out on, took me to the site.... LOGGED-IN as the user who'd posted the link, with the ability to view and update his profile on the site!
The site had made the very stupid mistake of putting the session identifier in the URL (D'oh). So completely legitimate traffic, security problem identified. But if I report it, they could easily scream "hacker" and I'd have a world of hassle to deal with which I don't need. so I quietly told the forum poster, he removed the link and I went on my way..
So there is a fine line here. Find a problem through legitimate traffic fine... Think "ooh a problem, what happens if I try ' OR 1=1;-- " not so fine.
What might be good would be a mechanism for people to report suspected problems to a central point anonymously that could then notify site owners...
Oracle Database Listener Security Guide < Eddie Awad’s Blog
There's a link to a good solid Oracle Listener security guide over at Eddie Awad's blog.
The link to the doc. itself is here .
The doc. does a good job of covering off what is a reasonably poorly understood area of Oracle security, well worth a read if it's an area you're involved in, or at least worth forwarding to your DBA's as I'd be willing to bet that many of them aren't aware of how insecure the listener is by default...