Managing and Auditing Electronic Data Interchange

At my last job, I helped implement an EDI solution that ultimately saved our sales team a tremendous amount of tedious manual entry, reduced the amount of time it took to process, pick, pack and ship orders, and significantly cut down on the number of errors made throughout the entire process.

My company entered a business relationship with a large retail chain of stores that purchased a variety of items from us. Each store was responsible for its own purchases, so before we implemented the EDI solution, each store would call or fax their orders to our sales reps, who would then manually key the orders into our system. This works very well if your customer only has four or five stores. But our customer had over 1500 stores, and could easily overwhelm our sales staff with orders.
This is how our EDI process worked:
  • Our customer would upload their purchase orders to the third party EDI site.
  • We would download the orders and import them into our system.
  • We would process, pick, pack and ship the orders.
  • We would upload our invoices for those orders to the third party EDI site.
  • Our customer would download the invoices from the third party EDI site, process them, and ultimately pay us.
We used the third party EDI site to manage EDI transactions for several smaller customers as well. The great thing about using a third party EDI site was we could concentrate on selling things, our customer could concentrate on buying things, and our third party EDI site could concentrate on securing the transactions and keeping the process rolling. I think using a third party to manage your EDI needs is comparable to hiring someone else to host your organization’s email, or migrating your servers to a cloud environment.

Serious Apple SSL Vulnerability Caused by Coding Error

Chapter 3 of the textbook, 3rdEdition, discusses Operating Systems and Networks, and briefly touches upon security protocols. On Friday, February 21st, Apple announced that there was a serious, fundamental vulnerability in the way iOS devices, such as iPhones and iPads; as well as OS X based computers, such as iMacs and MacBook Pros, utilized the Secure Sockets Layer protocol (SSL) to verify that encryption keys were digitally signed, or vouched for, by the owners of websites. (Lutz 2014).

To summarize the issue, SSL verification was being bypassed due to a simple typo in the underlying code. The typo looks like this:

if (err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)       goto fail;       goto fail;

goto fail

goto fail

Image of Apple’s SSL code is fromWired.com (Poulsen 2014)

 

In the event of an error, the first goto command skips to the section “fail”.The second goto command is a typo. If there is no error, the second goto command also forces the code to go to the section “fail”. It is considered a poor programing practice to use goto commands in modern coding. (Poulsen 2014).

Chaouki Bekrar, CEO and Head of Research at VUPEN, told SecurityWeek, “While this flaw itself does not allow an attacker to compromise a vulnerable device, it is still a very serious threat to the privacy of users as it can be exploited through MitM (Man-in-the-Middle) [attacks].” (Lennon 2014). If a user connects to an untrusted WIFI network, such as at a hotel, a coffee shop, or at the airport, an attacker could view communications between a user and a supposedly secure website such as the user’s bank, because the communication is not being encrypted.

Users are strongly encouraged to install the latest update for the iOS. An update was posted for iOS 6 on Saturday, February 22nd, and an update for iOS 7 was released Sunday, Febraury 23rd. As of February 23rd, Apple has not released an update for OS X.

Apple users can check whether or not their devices are vulnerable by going to the following website:  https://gotofail.com/. Visitors of the site will see a message showing that SSL Encryption is not working properly (Poulsen 2014).

This is one of the reasons why it’s important for us to follow technology news and keep our personal devices, as well as organizational devices patched and up to date. I have used this site to personally verify that my wife’s iPhone, her iMac, as well as my iPhone are vulnerable. I plan on updating all of my Apple devices as soon as possible.

 

Bibliography

Lennon, Mike. Apple Fixes Dangerous SSL Authentication Flaw in iOS. February 21, 2014. http://www.securityweek.com/apple-fixes-ssl-authentication-flaw-ios (accessed February 23, 2014).

Lutz, Jaime. iProblem: Apple Admits Products Vulnerable to Hackers. February 22, 2014. http://abcnews.go.com/m/blogEntry?id=22632968&ref=https%3A%2F%2Fwww.google.com%2F (accessed Februrary 22, 2014).

Poulsen, Kevin. Behind iPhone’s Critical Security Bug, a Single Bad ‘Goto’. February 22, 2014. http://www.wired.com/threatlevel/2014/02/gotofail/ (accessed February 23, 2014).

 

The Need for Audit Participation in the SDLC

I have been involved in one large scale migration from a legacy accounting/inventory system (10 + years old, which everyone said they hated) to a much more robust, modern system. We were a small company, so we were able to go to each user and verify what their roles were and which portions of the legacy system they used to do their job. We also received feedback about what they thought could be done to make their jobs easier.

Of course, once we deployed the new system, many of the users said they missed the old system, which just months  earlier they had been loudly complaining about! However, within six months the complaints had died down, and most employees were fairly satisfied with the new system.
In my opinion, if we hadn’t done the initial outreach, user dissatisfaction with the new system would’ve been much more vocal, and lasted much, much longer. It would’ve been no fun to be stuck in staff meetings, endlessly listening to users complain about a system that we had sunk a lot of time, money, and effort into.

Systems Maintenance Overview

We discussed the Systems Development Life Cycle (SDLC) this week, which is the process an organization goes through to develop its information system. The text book, (3rd Edition) gave us an overview of the components of the SDLC. The last component, Program Change Procedures, is also known as Systems Maintenance, and is an area that could cause a lot of problems for the organization if it’s not implemented properly.

Systems Maintenance can be viewed as a process of moving program changes from a Development environment, through Integration and Staging Environments, and into the Production Environment. This is a fairly complex process, but if managed properly, it can reduce the number of potential errors released into a Production Environment.

This is a brief overview of the different kinds of environments:

Development Environment: This is an isolated environment where developers make coding changes without affecting the rest of the team. Development environments can be configured for individual developers or small teams.

Integration Environment: At this stage, coding changes made in the Development Environment are brought forward and integrated with the work of the entire project team. This is intended to test the changes made by the developers before they are pushed up to the Staging Environment. It is possible for the Development and Integration Environments to be the same environment. For testing purposes, developers should use a subset of the data in the Production Environment.

Staging Environment: Should be configured to simulate the Production Environment as closely as possible. If possible, the Staging Environment should utilize a copy of the entire database, not a subset of it. It should also have a similar hardware configuration so that it’s possible to accurately forecast performance.

Production Environment: Real world environment. It could consist of one machine or many machines.

Below is a chart that illustrates the process of moving coding changes, made by developers, from the Development Environment, through the Integration and Staging Environments, and into the Production Environment.

Systems Maintenance

Systems Maintenance

This chart is based on the chart displayed in the article. (Murray 2013)

1. Developers write code changes in Development Environment.

2. Code changes are then moved into Integration Environment and checked into the Source Program Library (SPL).

3. Bugs are found in the Integration Environment. Bug Reports are sent back to the developers.

4. Developers fix bugs in Development Environment.

5. Changes are pushed into Integration Environment and checked into the SPL.

6. The Release Manager reviews code changes in Integration Environment.

7. Changes are promoted to Staging Environment.

8. QA team tests changes in the Staging Environment.

9. QA finds bugs in the Staging Environment, sends Bug Reports back to the Developers.

10. Developers fix bugs in the Development Environment.

11. Code changes are pushed into the Integration Environment.

12. Release Manager promotes code changes into the Staging Environment.

13. Release Manager reviews changes and issues “Ok to Release”

14. Code is packaged and given a release version number.

15. Code Packages are promoted to the Production Environment.

16. Bugs are found in the Production Environment, Bug Reports are sent back to the Developers.

17. Developers fix bugs in Development Environment.

18. Changes are pushed into Integration Environment and checked into the SPL.  (Murray 2013)

 

Systems Maintenance is a fairly complex process, and is ongoing. As can be seen above, it’s very important to have a Source Program Library controlled by SPL Management Software that controls access to the code, manages development, and tracks changes.

 

Bibliography

Murray, Peter. Traditional Development/Integration/Staging/Production Practice for Software Development. September 25, 2013. http://dltj.org/article/software-development-practice/ (accessed February 17, 2014).

 

NSA Vs. Commercial Data Mining – Fight!

As much data mining as the NSA has been conducting, there should also be a discussion regarding commercial data mining.

Every time I hand the sales clerk my Barnes and Noble or Acme membership card, I expect to receive a discount on my purchase. However, there is no such thing as a free lunch. They give me a discount in exchange for my tacit permission to use my purchasing information. Based on that information, they can build a profile of who they think I am, what kinds of products I would be interested in buying, and how to target me.
I like to think that I have a fairly sophisticated and realistic understanding of how this kind of technology works. And yet I am still amazed and awestruck at the level of targeting Amazon is capable of aiming directly at me, including customized emails containing books and movies I might be interested in based on my purchases and browsing history.
The discounts are great, but we don’t really have much say as to what these companies do with that information, or who they sell it to, after they acquire it from us. Heck, they could be selling our consumer information directly to the NSA!
In the end, I think we may have more to fear from Amazon, Acme and Barnes and Noble than we do from the NSA.

Protecting Databases from Inference Attacks

Inference Controls  are methods for preventing unauthorized users from accessing sensitive information by using lower level data to infer the existence of higher level, sensitive data.

One method of obtaining sensitive data is to use a series of innocuous data queries that individually select non-sensitive information and don’t trigger Database Management System (DBMS) security. But taken together, these data queries can be used to infer the existence of higher level, sensitive data by mapping out a series of Association Rules that give attackers a better idea of what the sensitive information is.

In the following example, the bank wants to hide whether or not any given customer has a Preferred Status of “High” (balances over $2,000) from lower level users such as bank tellers. Higher level users, such as loan officers or bank managers, have access to this information and use it to determine if the customer is eligible for mortgages or loans.

Acct # Name Address Preferred Status Balance
1001 Pete Parker 1450 Baltic Ave Low $250
1002 Franklin Castle 34 Vermont Ave Low $350
1003 Jane Doe 15 St. James Place Mod $1,050
1004 M.J. Watson 25 Illinois Ave Mod $1,500
1005 Antonio Stark 56 Park Place High $3,000
1006 Susan Storm 56 Boardwalk High $3,000

The default security system could prevent bank tellers from directly querying the database to find out if a customer has a Preferred Status of “High”. However, by using the following queries, it may not be able to prevent them from inferring Preferred Status Association Rules:

Query 1: If Balance < $2,000 then Preferred Status = “Medium” or “Low”.

Query 2: Display list of customers who do not appear in Query 1.
This example is based on an example in (Raman 2001). It is possible to guard against these types of attacks by using advanced data mining techniques to map out potential Association Rules and guarding against them. (Chen Li 2006)

In another example, it may be possible to infer the backend structure of a database by utilizing a SQL Injection attack. In the following example, we would submit a specially formatted SQL query into one of the input fields of a web page or embedding it in the URL of that web page, to force the web site to display a database error message that reveals more information about the backend database.

The query might be:  SELECT name from authors where username = ‘’ AND password=’’ AND ‘pin = convert (int,(select top 1 name from sysobjects where xtype=’u’))  In this example, if the backend database is a Microsoft SQL Server database, the injected SQL could force the website to return the following error message: “Microsoft OLE DB Provider for SQL Server (0x80040E07) Error converting nvarchar value ’CreditCards’ to a column of data type int.”

From this error message, we could infer that the web site is using Microsoft SQL Server, and that one of the data tables is called “CreditCards”.

There are a number of methods that can be used to prevent SQL Injection attacks. Here are several:

  • Configure database accounts with limited permissions.
  • Use application specific database accounts. If a website connects to a database, configure the website to use a website specific database account.
  • Check input types – determine whether an input is a string or an integer before submitting to the back end database.
  • Hide or conceal error messages, to prevent back end database information from being displayed to attackers. (Kissoon 2013)

In conclusion, it is possible for an attacker to obtain high level, sensitive information and database schemas by building Association Rules from lower level data queries or SQL Injection attacks. But we can use various techniques to guard against these Inference Attacks.

Bibliography

Chen Li, Houtan Shirani-Mehr, Xiaochun Yang. Protecting Individual Information Against Attacks in Data Publishing. December 30, 2006. http://www.ics.uci.edu/~chenli/pub/2007-dasfaa.pdf (accessed February 9, 2014).

Kissoon, Joshua. SQL Injection In-Depth: Attacks and Prevention Methods. June 12, 2013. http://www.cleverlogic.net/articles/sql-injection-depth-attacks-and-prevention-methods (accessed February 9, 2014).

Raman, Sangeetha. Detecting Inference Attacks Using Association Rules. December 13, 2001. http://andromeda.rutgers.edu/~gshafer/raman.pdf (accessed February 9, 2014).

Protecting Databases from Inference Attacks

This week we discussed Data Management System auditing. The textbook (3rd Edition) reviewed Inference Controls. These are methods for preventing unauthorized users from accessing sensitive information by using lower level data to infer the existence of higher level, sensitive data.

One method of obtaining sensitive data is to use a series of innocuous data queries that individually select non-sensitive information and don’t trigger Database Management System (DBMS) security. But taken together, these data queries can be used to infer the existence of higher level, sensitive data by mapping out a series of Association Rules that give attackers a better idea of what the sensitive information is.

In the following example, the bank wants to hide whether or not any given customer has a Preferred Status of “High” (balances over $2,000) from lower level users such as bank tellers. Higher level users, such as loan officers or bank managers, have access to this information and use it to determine if the customer is eligible for mortgages or loans.

Acct # Name Address Preferred Status Balance
1001 Pete Parker 1450 Baltic Ave Low $250
1002 Franklin Castle 34 Vermont Ave Low $350
1003 Jane Doe 15 St. James Place Mod $1,050
1004 M.J. Watson 25 Illinois Ave Mod $1,500
1005 Antonio Stark 56 Park Place High $3,000
1006 Susan Storm 56 Boardwalk High $3,000

The default security system could prevent bank tellers from directly querying the database to find out if a customer has a Preferred Status of “High”. However, by using the following queries, it may not be able to prevent them from inferring Preferred Status Association Rules:

Query 1: If Balance < $2,000 then Preferred Status = “Medium” or “Low”.

Query 2: Display list of customers who do not appear in Query 1.
This example is based on an example in (Raman 2001). It is possible to guard against these types of attacks by using advanced data mining techniques to map out potential Association Rules and guarding against them. (Chen Li 2006)

In another example, it may be possible to infer the backend structure of a database by utilizing a SQL Injection attack. In the following example, we would submit a specially formatted SQL query into one of the input fields of a web page or embedding it in the URL of that web page, to force the web site to display a database error message that reveals more information about the backend database.

The query might be:  SELECT name from authors where username = ‘’ AND password=’’ AND ‘pin = convert (int,(select top 1 name from sysobjects where xtype=’u’))  In this example, if the backend database is a Microsoft SQL Server database, the injected SQL could force the website to return the following error message: “Microsoft OLE DB Provider for SQL Server (0x80040E07) Error converting nvarchar value ’CreditCards’ to a column of data type int.”

From this error message, we could infer that the web site is using Microsoft SQL Server, and that one of the data tables is called “CreditCards”.

There are a number of methods that can be used to prevent SQL Injection attacks. Here are several:

  • Configure database accounts with limited permissions.
  • Use application specific database accounts. If a website connects to a database, configure the website to use a website specific database account.
  • Check input types – determine whether an input is a string or an integer before submitting to the back end database.
  • Hide or conceal error messages, to prevent back end database information from being displayed to attackers. (Kissoon 2013)

In conclusion, it is possible for an attacker to obtain high level, sensitive information and database schemas by building Association Rules from lower level data queries or SQL Injection attacks. But we can use various techniques to guard against these Inference Attacks.

Bibliography

Chen Li, Houtan Shirani-Mehr, Xiaochun Yang. Protecting Individual Information Against Attacks in Data Publishing. December 30, 2006. http://www.ics.uci.edu/~chenli/pub/2007-dasfaa.pdf (accessed February 9, 2014).

Kissoon, Joshua. SQL Injection In-Depth: Attacks and Prevention Methods. June 12, 2013. http://www.cleverlogic.net/articles/sql-injection-depth-attacks-and-prevention-methods (accessed February 9, 2014).

Raman, Sangeetha. Detecting Inference Attacks Using Association Rules. December 13, 2001. http://andromeda.rutgers.edu/~gshafer/raman.pdf (accessed February 9, 2014).

Importance of IT governance

I used to think that terms like “Corporate Governance” and “IT Governance” were so much management-speak: mumbo jumbo that upper managers throw around to justify their titles and salaries.

However, I have just researched the $7.2 BILLION loss for the French bank Société General that occurred when a rogue trader spent billions of euros on unauthorized transactions. These transactions put the bank in tremendous jeopardy and cost the bank $7.2 billion to clean up his mess.
He was able to do this, in part, due to an appalling lack of oversight and controls on his transactions, as well as the inappropriate use of account log-ins he had acquired over the years.
These glaring weaknesses tie right back into inadequate IT Governance. If Société General had been more serious about IT Governance, there’s a good chance that this particular scandal would’ve been discovered much sooner, cost much less money, and prevented a huge hit to their reputation.

Poor IT Governance Contributed to $7.2 Billion loss for bank

In 2008, the French bank Societe Generale lost €4.9 Billion ($7.2 Billion) when it was discovered that one of their traders, Jerome Kerviel, had been using fictitious trades to offset €50 Billion worth of trades, far exceeding his buying authority.

Kerviel’s job at Societe Generale was to “hedge” trades, making some trades that bet on the market going up, and other trades betting on the market going down. The idea was that most of these trades would cancel out, but on a good day Societe General could make a little money on a large number of trades, while on a bad day it wouldn’t lose much money. Starting in November 2005, he began using a riskier strategy to increase the amount of money Societe General made on these bets by exceeding his buying authority and placing less mony on trades betting the market would go down, and more money on trades betting that the market would go up. If these bets paid off, Societe General would make a lot more money, and he’d look like a hero to management, earning him promotions and bonuses. He made Societe Generale almost $2 billion dollars before the market started turning and things started going south.

He was able to exceed his buying authority by creating a series of fake trades betting that the market would go down, which gave the illusion that overall his books were balanced. When he bet €50 Billion that the market would go in a certain direction, he put Societe Generale at great risk, because it wouldn’t be able to cover the full amount if the market went down.

How was he able to do this? Before being promoted to a trading position at the bank, Kerviel had worked in the back office, and became very familiar with systems, processes, usernames and passwords. When he was promoted to the trading floor, he used this knowledge to create numerous, short term, fake trades that existed in the system long enough to balance his riskier trades. These short term trades were cancelled out of the system before they could be fully processed. (Gauthier-Villars, 2008)

Several times alarms were raised in the system about these trades, but Kerviel was able to explain them away as either mistakes on his part, or produce fake emails that supported what he was doing.

In November 2007, enough suspicions at the bank were finally raised that they began conducting an investigation. As a result, the bank began unwinding Kerviel’s trades as quickly as possible. The process of unwinding these trades cost the bank €4.9 Billion before the nature of his fraud was made public. (Sarup, 2008)

This event ties directly into what we studied in chapter 2 of the text book. Corporate and IT Governance at Societe General were certainly lacking. Jerome Kerviel should not have been able to carry out his plan for almost three years before being caught. Initially, there was inadequate investigation into alarms raised by his activities. There was a failure to review all his transactions, and a failure of the controls that should’ve prevented him from making false transactions to begin with. This incident also highlights the need to forcefully separate certain corporate functions (in this case, back office versus the trading floor) and better manage user access controls in both environments.

Bibliography

Gauthier-Villars, David, and Carrick Mollenkamp. Société Générale Blew Chances To Nab Trader. January 29, 2008. http://online.wsj.com/news/articles/SB120151007395521821 (accessed February 2, 2014).

Sarup, CISA, FCA, Deepak. A Rogue Trader Strikes Again! Taking Advantage of the Lack of Basic Internal Controls. Volume 4 2008. http://www.isaca.org/Journal/Past-Issues/2008/Volume-4/Pages/A-Rogue-Trader-Strikes-Again-1.aspx (accessed February 2, 2014).