NoticeBored blog

Mike Blakley wrote a fine piece in EDPACS on using SQL queries to interrogate a database system for audit purposes.

Abstract:

"Organizations, both large and small, are increasingly reliant on database systems for their operational support needs. This is due to the adoption of accounting systems ranging from large enterprise resource planning systems, down to departmental or even desktop-based database systems. The traditional audit approach used to account for data stored in databases has relied on information technology or other support staff to extract data for audit, which was then tested by others, often technical specialists. An alternative approach, which also provides greater audit independence, is to increase the knowledge level and skills of audit staff so they can obtain this data directly and perform their audit tests independently. This article may have relevance to other IT system audits."

In the same issue, Fred Cohen discusses the specification of control requirements for [real-time process] control systems and SCADA, an area that relatively few information security managers and IT auditors have experienced. I have had some exposure to this at power generation and engineering companies but admit I know next to nothing about it. Having seen conference presentations on "exploring" SCADA networks and Building Management Systems, I'm sure these are targets for curious hackers who relish the challenge of understanding obscure comms protocols and exploiting inadequate security controls. Fred's comments about the ever-deepening Internet connectedness of such networks and the historical lack of attention to security ring very true. I often wonder what fun would lay in store for hackers with access to the networks and devices, perhaps exploiting the numerous wireless command and control systems out there. Let's hope they are responsible enough to use their powers for good not evil.

All in all, another excellent issue. [The fact that I'm one of many on the EDPACS editorial board is purely coincidental, of course!]

Labels: Audit, Database, Hacking, Infosec, Network

A 46-page academic paper by Richard Thompson Ainsworth of Boston University School of Law describes "zappers" - programs designed to divert some sales transactions from the normal sales processing and accounting systems. Fraudsters with sufficient access to an organization's sales systems (e.g. small business owners) sometimes use zappers either to misappopriate the entire sales income for the diverted sales (steal the entire value from the company - the sales don't go through the books) or to to manipulate the value (for example to steal the VAT/GST/sales tax content).

So-called "zap" and "super-zap" programs have existed for decades in the mainframe world. They allow intervention on databases, overriding normal access constraints to manipulate the data, and potentially programs, directly. They are supposed to be used only under carefully controlled emergency conditions, for instance to modify or delete a rogue data record that is somehow blocking an entire batch from processing. Most competent sysprogs (systems programmers) or systems administrators have the knowledge and capability to run zap programs and can potentially meddle with the systems in a virtually unstoppable and undetecable manner, if they are careful anyway: well-written programs have built-in integrity checks and other controls that at least identify and flag direct interventions. Unfortunately, if the sysprogs also have the capability to suspend or edit the audit trails, or substitute hacked programs, or subvert the operating system calls, or ... or ... all bets are off. Remember this possibility if you ever hear a sysprog for a financial institution bragging about the speed of his new Ferrari.

Going back to sales zappers, the article points out differences in the ways such frauds are detected in the UK and EU. In the States, it seems the evidence suggests that income tax investigations "often" (or rather occasionally!) catch zapper users, while in EU they are more likely to be caught by sales tax investigations. This begs the question: why not do both? And while you're at it, why not take a close look at those "shrinkage" stock losses - the ones that conceal employee as well as customer thefts of goods?

Labels: Database, Fraud, Integrity, Trust

A Ponemon Institute survey into database security found that:

"- Trusted insiders remain a significant, and largely unmonitored risk
- A majority of organizations do not have the technology or processes required to effectively manage against insider threat
- Due to perceived business value, many large organizations assign lower priority to the protection of customer and employee data versus intellectual property
- The vast majority of data exposed in the past two years has been confidential customer and employee information.
The survey found that “trusted” insiders’ ability to compromise critical data is the most serious concern for respondent organizations. Despite this concern, fifty-seven percent of those surveyed do not believe that their organizations have taken adequate measures to protect against malicious insiders and fifty-five percent do not believe that they have taken adequate measures to protect against “data loss.”
The survey also found that despite being aware of these threats, inadequate protection of corporate databases is the norm rather than the exception. Forty percent of those surveyed do not have the mechanisms in place, or are unaware of whether databases are monitored for suspicious activity. This shortfall can be attributed to the massive scale of corporate data stores and the lack of IT resources. Eighty-eight percent of those surveyed manage greater than one hundred databases and a majority of respondents manage in excess of 500 databases."

Although the survey was sponsored by a company with a vested interest in database security, the survey sample was large enough for the results to be statistically significant. The Ponemon Institute is a respected survey institution, for instance including notes in the report about possible biases in the respondants and responses. To a non-scientist, it may seem perverse that pointing out possible weaknesses in the method actually makes is stronger, but better that than to ignore or gloss over them.

As to what needs to be done about database security, the survey commentary merely suggests a few hints e.g.:

"Among core security and IT professionals, operational efficiencies and system optimization are consistently higher priorities than efforts related to Sarbanes-Oxley, PCI, NIST 800-53 or other similar compliance initiatives ... our results show that intellectual property and business confidential information in databases is not generally protected. Even in the face of frequent, expensive, and highly publicized breaches, respondents have not made protecting customer and employee information a high priority."

... so priorities need to be adjusted (but how?).

Perhaps Lloyds TSB has (part of) the answer?

Labels: Database, Insider, Privacy, Secrecy

It's been a full-on blogging day. Here's a little security awareness nugget for all you hungry SQL programmers Out There:

sqlmap is an automatic blind SQL injection tool, developed in python, capable to perform an active database fingerprint, to enumerate entire remote database and much more. The aim of this project is to implement a fully functional database mapper tool which takes advantages of web application programming security flaws which lead to SQL injection vulnerabilities.

Good luck!

More database security links

Labels: Database

A database hacking incident at TJX has evidently exposed bank card and drivers’ license details of millions of customers at its American, Canadian and Perto Rican TK Maxx and other stores. The systems appear to have been hacked as far back as July 2005, some 18 months before the incident was discovered. [Generally speaking, credit card database hackers often kill the goose that lays the golden eggs by exploiting so many cards that they are traced back to the hacked originator in much less than 18 months. Perhaps the TJX hackers only recently obtained sufficient information to exploit, or perhaps they are true hackers not crackers, in other words they were driven by curiosity not malice and greed. This story is still unfolding.]

More database security, hacking, identity theft and incident management links

Labels: Database, Hacking, ID theft, Incidents

A glitch in Flickr's database processing resulted in the occasional presentation of random pictures from the cache rather than the ones requested. No doubt some of the pictures were quite a surprise to customers expecting to see their holiday snaps. A red-faced explanation and apology is a shining example of the value of coming clean after an incident, although personally I would have liked more information about the technical issues.

More database security and incident management links

Labels: Database, Incidents

Scuba looks like an interesting option to supplement your regular pre-release security assessment processes and tools:

Scuba by Imperva is a free, lightweight Java utility that scans Oracle, DB2, MS-SQL, and Sybase databases for known vulnerabilities and configuration flaws. Based on its assessment results, Scuba creates clear, informative reports with detailed test descriptions. Summary reports, available in Java and HTML format, illustrate overall risk level. With Scuba by Imperva, you are quickly on your way to meeting industry-leading best practices for database configuration and management.

More database security links

Labels: Database, Development

A database application error (presumably) led to a customer of HBOS (Halifax Bank of Scotland) being sent 75,000 statements for other customers when she requested hers.

Ms McLaughlan, of Netherkirkgate, Aberdeen, said: "I sent away for my bank statements to get a refund on some bank charges. A couple of days later these five packages turned up at my door and they were filled with people's names, credit numbers, what they had paid in, and had taken out every day. The details started from April 2003 and there was also the total of the bank's overdraft."

This is exactly the kind of gross error that output validation is meant to detect and stop. Whilst it is vaguely conceivable that someone may legitimately request such a huge number of statements, the chances are remote enough to make this an exceptional request that can be flagged and held pending human intervention. Of course, it is also quite possible that the HBOS systems did indeed flag this one and someone mistakenly released the output. Doh!

More database security links

Labels: Database

Here are just two of this week's stories about the theft of IT systems holding unencrypted databases of personal data.

Firstly, the US Department of Veterans Affairs ("the VA") has reported a portable hard drive containing personal data on vets lost, presumed stolen. A laptop computer containing the social security numbers of 26.5 million veterans was stolen from a VA official's home last May and another computer containing personal information on up to 38,000 veterans went missing last August. The VA is belatedly installing encryption software on its laptops at least, if not also its portable drives and desktops.

Secondly, a US accountant's stolen PC contains details of 800 clients for whom she had prepared tax returns. The thieves appear to have targeted the PC specifically since they left behind cash and checks.

More database security links

Labels: Database, Privacy

We have just released a brand new awareness module on database security for February. The risks and controls associated with database security make for a fascinating security awareness subject.

For IT professionals, the module contains:
- A risk analysis (available in the NoticeBored newsletter)
- A PowerPoint presentation giving an overview of database security technologies
- A white paper describing database security controls in more depth
- A controls matrix categorizing database security controls into preventive, detective and corrective classes on one axis, and confidentiality, integrity and availability on the other
- And a checklist to guide a systematic review of database security controls.

For the general staff audience, the non-technical posters, seminar slides, screensavers, case study, crossword and other awareness materials highlight personal perspectives on database security, for example when database breaches lead to the exposure of personal data.

Finally, we present the governance aspects of database security to management through mind maps, agendas, PowerPoint slides and briefing papers. Managers need to be aware of the legal and regulatory implications of database security failures. The generic business case for database security controls provides a solid background for managers to assess the security aspects of database development project proposals, and the metrics paper suggests a range of ways in which they can keep an eye on their investments in database security.

See the module contents and links page

Labels: Awareness, Database

"More and more government agencies post public records online, making a startling amount of information available. With a little amateur sleuthing, you can peek into the backgrounds of the people you let into your life -- a nanny or housekeeper, an online acquaintance, a potential business partner -- and be reasonably satisfied they're not predators or crooks." The Seattle Times piece It's never been easier to be your own detective goes on to explain how easy it is to conduct background checks online, whether using do-it-yourself web search techniques or paying a few dollars for others to check on your behalf. While most database records are legitimately placed in the public domain in this fashion, it is equally possible that supposedly private databases could be hacked and end up on underground websites somewhere. The article also makes the point that you cannot necessarily trust everything you read online. Quite apart from the possibility of finding information about someone else with similar details to the person you are checking, the information available online is only as good as that stored in the database.

More database security and privacy links

Labels: Database, Privacy

Oracle, which "leads in customer relationship management" according to its home page has released a shed-load of patches containing : 22 security fixes for Oracle Database; 6 security fixes for Oracle HTTP Server; 35 security fixes for Oracle Application Express; 14 security fixes for Oracle Application Server; 13 security fixes for Oracle E-Business Suite; 8 security fixes for Oracle PeopleSoft Enterprise PeopleTools and Enterprise Portal Solutions; 1 security fix for JD Edwards EnterpriseOne; 1 security fix for Oracle Pharmaceutical Applications; and a partridge in a pear tree. If you run Oracle software, get busy with the patching to miminize the risk of incidents. If you work for Oracle, how about some of that customer relationship management i.e. better quality software for your valued customers?
More links on incident management and bugs!

Labels: Bugs, Database, Incidents

The Australian Taxation Office has taken action against 27 employees for inappropriate access to taxpayers' personal data. Two were prosecuted under the Tax Administration Act. This story, coupled with last week's revelation about a similar issue at Centrelink and news of similar crackdowns at other Australian government bodies, presumably indicates a hardening of attitudes. Employees don't seem to realise that the database systems they access may record all sorts of incriminating evidence in their logs. Presumably the relevant audit functions have been looking closely at the records.
More identity theft links

Labels: Audit, Database

Around 100 staff have resigned, 19 have been sacked and around 350 have been disciplined as a result of a two-year investigation into their unauthorized use of database facilities at Centrelink, the Australian federal government's social security and welfare agency. As such, Centrelink staff have access to a wide range of personal information. Five cases were serious enough to be referred to the federal police. It is reported that spyware was used to track staff use of the systems. A Centrelink general manager said "It was done for a whole range of reasons - from just sticky-beaking, through to at the more serious end of records actually being changed ... What this shows is that we have zero tolerance for any people who have surfed the details of the family and friends or peeked at records of their neighbours in our system." This statement fails to acknowledge the potential for abusing such wideranging access to personal data in order to commit identity theft.
More identity theft resources

Labels: Database, Incidents, Privacy, Secrecy

Valuable paper-based records archived in an Iron Mountain storage facility in East London have been lost in a huge fire. The storage warehouse was apparently "full of paper", such that the fire was expected to rage for a day or two. The cause of the fire was unknown (as of July 13th anyway). Naturally, Iron Mountain's more sensible customers will have taken the precaution of copying their valuable archive materials and storing them separately in diverse, well-protected and secured storage facilities - won't they? Remember this story when you are moving that vital database file to your archive tapes or CDs. If that is the only remaining copy, when it's gone it's gone. Toast.
Iron Mountain's press release takes an admirably responsible position: "Iron Mountain already invests heavily and emphasises security as a normal operating principle. Due to the unknown cause of the fire at this time, we are taking extra precautions to supplement our current high level of security: Increased security staff has been added to all London facilities; Conducting an out of cycle review of background checks on personnel; Auditing external agencies and internal security assessments; Re-issuing of vendor background checks; Re-implementation of security awareness of all internal employees; Performing an out-of-cycle inspection of all Iron Mountain vehicles." [That last one could be an obtuse reference to the possible cause of the fire, or perhaps to the fact that so many couriers seem to lose their cargoes in transit]. Nevertheless, Iron Mountain's customers' misfortune is Iron Mountain's misfortune too. A lot more than just a pile of paper went up in smoke on July 12th.
More IT resilience and DR links

Labels: Availability, Awareness, Database

A raft of new or updated security checklists and verification tools have been released by NIST covering: access control; application & database security; DNS; Enclave; .NET framework; network infrastructure; SAN/sharing peripherals across the network; UNIX; VoIP; and Windows 2000, XP and 2003 Server. The combination of comprehensive security checklists recommending specific parameter settings and automated tools to check system configurations against the recommendations makes the security manager's job that bit easier.
More IT Ops & system security links

Labels: Database, Network

A log collation and analysis utility called Splunk (tagline "take the SH out of IT") looks like a cool solution for those who need to manage security logs from multiple sources (e.g. Apache, IIS, Windows event logs etc.). Suck all your logs into the database on a convenient spare Linux or Solaris or FreeBSD or MacOs server, and search the whole lot through a Google-like front end. Look for strange events and unusual patterns. Sift the wheat from the chaff. It's a boon for small businesses with budgetarily-challenged sysadmins since it's free for up to 500 Mb of logs per day, while the extended Pro versions look neat too for grown-up enterprises - not least because there's a wiki with answers from the user community to "What's that in my log?"-type questions (a great idea for other software vendors - hint hint). The Splunk FAQ hints at the limitations of alternatives such as Syslog-ng, although the Windows-based Kiwi Syslog syslog concentrator strangely doesn't merit a mention.
More security links for IT Ops

Labels: Database

Further to our blog entry of April 10th, we received the following spam today:

Hey, You are recieving this email because you are a member of BlueSecurity (http://www.bluesecurity.com). You signed up because you were expecting to recieve a lesser amount of spam, unfortunately, due to the tactics used by BlueSecurity, you will end up recieving this message, or other nonsensical spams 20-40 times more than you would normally. How do you make it stop? Simple, in 48 hours, and every 48 hours thereafter, we will run our current list of BlueSecurity subscribers through BlueSecurity's database, if you arent there.. you wont get this again. We have devised a method to retrieve your address from their database, so by signing up and remaining a BlueSecurity user not only are you opening yourself up for this, you are also potentially verifying your email address through them to even more spammers, and will end up getting up even more spam as an end-result. By signing up for bluesecurity, you are doing the exact opposite of what you want, so delete your account, and you will stop recieving this. Why are we doing this? Its simple, we dont want to, but BlueSecurity is forcing us. We would much rather not waste our resources and send you these useless mails. Its simple, we dont want to, but BlueSecurity is forcing us. We would much rather not waste our resources and send you these useless mails, but do not believe for one second that we will stop this tirade of emails if you choose to stay with BlueSecurity. Just remember one thing when you read this, we didnt do this to you, BlueSecurity did. If BlueSecurity decides to play fair, we will do the same. Just remove yourself from BlueSecurity, and make it easier on you. Sergio Sheldon

Regardless of the veracity of the spammer's claim, regardless of the mechanism of the (alleged) compromise, I for one am not willing to take the risk. Blue Security is toast. Bye bye blue frog.

Labels: Database, Email, Risk

Cool free browser extension (IE and Firefox) that automatically checks websites you visit against its database, and warns you of potentially unsafe sites with a red button. The database has been compiled by automated and manual tests across "sites representing more than 95% of web traffic" looking for dubious practices such as excessive popups, spamming on emails submitted, spyware downloads, browser reconfiguration etc. Green/red/grey [untested] buttons magically appear next to each of the search results on Google and Yahoo too, so you get a heads-up before even visiting a site. Isn't the web a wonderous thing?
More Internet security links

Labels: Database

The NSA and CSI’s SNAC security configuration guides comprise a set of security standards for various operating systems (such as Windows, MacOS, Solaris), applications (such as Oracle, SQL Server, Exchange, Office, SMS, BEA Weblogic, IIS, IE and Netscape), network equipment (routers and switches) and more. If your management has endorsed your high-level and information security policies but the supporting technical standards are still ‘work in progress’, then take a look at SNAC.
More IT operations security resources

Labels: Database, Infosec, Network

Applications that are not securely written and configured can open security vulnerabilities that affect the whole system. A 2001 posting by Pete Finnegan, for instance, explains how, under the right (wrong!) circumstances, someone can reveal Oracle user passwords in clear text. Pete has published a fascinating set of papers on Oracle (in)security on his website.
More authentication resources here

Labels: Authentication, Database

Users of Oracle systems are advised to double-check that the patches they think they have applied have in fact been successfully applied. Inconsistencies in the internal inventory of Oracle programs maintained by an Oracle installation, for example, may result in relevant patches being missed. [The article is based on a somewhat self-serving press release by an Oracle specialist, but has a ring of truth. A similar situation applies to Microsoft: Microsoft Update does not always apply all relevant MS patches, so it is worth running something like Microsoft Baseline Security Analyzer every so often to double-check the installation. Regression testing and penetration testing can also be useful if sufficient resources are available to 'keep the lights on'.]
More change management resources

Labels: Database, Infosec

NIST's National Vulnerability Database reports an average of 8 new security vulnerabilities every day, with over 12,000 already listed. It's not difficult to see that keeping track of new vulnerabilities, assessing whether they are relevant, testing and applying patches to all relevant systems is no trivial matter for the average corporation. Any organization that lacks adequate IT resources must surely struggle.
More change management resources

Labels: Database

A rare insight to the change management problems caused by vulnerabilities disclosed by 'security researchers' is provided by the CSO of Oracle. She argues that although fixing an identified problem may only take a few minutes, it can be far more involved. Furthermore, she claims there are customer-friendly reasons for delaying the release of fixes [which seems just a tad far-fetched to me]. She also admits that one quarter of security fixes are a result of information provided by third parties, an amazing fact given that Oracle has complete 'glass box' access to its own source code and the best Oracle professionals on the planet at its disposal.
More change management resources

Labels: Database, Infosec