ERP Implementation: Big Bang versus Phased Implementation

We discuss Enterprise Resource Planning Systems (ERP), and strategies for implementing them. Implementation can be broken down into two major strategies.

The Big Bang strategy focuses on switching from the legacy system to the new ERP system in one shot, or “Big Bang”. This means switching from the old to the new system across all departments, and at all levels, all at once.

There are a number of advantages to the Big Bang strategy. It tends to have a lower implementation cost because implementation occurs over a shorter time frame. The number of issues that inevitably crop up tend to occur during this shorter period of time. If everything goes according to plan, systems implemented under the Big Bang strategy are up and running on the first day, and legacy systems do not need to run simultaneously with the new system.

There are also a number of potential disadvantages to the Big Bang strategy. Because a Big Bang implementation occurs at all levels of the organization and across departments, there is a higher chance of technical problems, which makes implementation riskier. There is also a near term impact on productivity because there is a shorter time to o train employees on the new system. (International Business Systems 2013)

 

Big Bang Theory

Big Bang Theory

The Phased Implementation strategy focuses on phasing out portions of the legacy system and phasing in the new system in stages, or phases, instead of replacing the entire system all at once.

There are a number of advantages to implementing the Phased Implementation strategy. There is a lower risk to implement this strategy because only a portion of the system is being replaced at any given time, instead of the entire system. If there is a problem, there is more time to resolve the issues and test. There is also more time to train employees.

There are also a number of potential disadvantages to the Phased Implementation strategy.

It takes longer to implement because portions of the system are being replaced. This means that the company has to temporarily connect the old system to the new system as the new system is being phased in. It is also possible that there will be disruptions to inter-departmental business processes during this process. (International Business Systems 2013)

 

Phased Implementation

Phased Implementation

The article notes that neither strategy is better than the other. Whether an organization uses the Big Bang strategy or the Phased Implementation strategy depends on the business requirements of the organization itself, the scale of the organization, IT infrastructure and preparedness.

Bibliography

International Business Systems. How to Implement ERP for Your Business: All at Once or In Phases? August 02, 2013. http://globial.com/globialtalksbusiness/how-to-implement-erp-for-your-business-all-at-once-or-in-phases/ (accessed March 02, 2014).

 

Scrooge McDuck vs. the Consultants

Several years ago I was involved in the process of migrating the U.S. branch of my company from an ancient Pick D3 system to the much more modern SAP Business One, which is an ERP system for smaller businesses.

The Australian branch of our company brought in a team of consultants and let them drive their conversion. Because the Australians let the consultants move the process forward, that side of the company spent almost a year haunted by issues related to their “Big Bang” implementation of SAP Business One.

My boss, who I thought could, at times, be incredibly abrasive and nit picky, ended up doing an amazing job of driving the process in the U.S. He had us map out every user’s data needs, worked with me on our data conversion process, and laid out a plan for implementing a hard cutover date to the new system, while allowing us to continue to refer back to the legacy system to validate our business processes.
I believe that the key difference between the two implementations was that the Australian branch relied to much on the consultants to drive the process, whereas my boss rolled up his sleeves and drove the process himself. At the end of the day, consultants are concerned about billable hours and being paid for project completion. They are not nearly as passionate about the data and internal processes as the users will be.
Based on my experience, consultants may initially know the system they are selling better than the customer, but they don’t know your company’s processes, and won’t be as passionate and precise about getting it right the first time. Your companies IT office should be heavily involved in this process from the start and be the ones pushing it forward.

Millions of Account Credentials found in the Wild

In this recent PC World article,
http://www.pcworld.com/article/2102120/360-million-account-credentials-found-in-the-wild-says-security-firm.html, cyber security researchers studying underground black market forums were able to uncover a list of 360 MILLION account credentials, which were probably collected through multiple retail and corporate data breaches.
The company that uncovered this trove of user credentials is Hold Security, LLC. They estimate that that roughly 30% of these credentials, 105 million credentials, contained email addresses and passwords, and may have come from job-search and dating web sites.
The article surmises that while it’s possible that some of these credentials were gathered using malware installed on individual computers, the sheer scale of the data suggests that attackers have changed tactics, are now focusing on acquiring large stores of data from companies instead of individuals.
This underscores how critical security is for companies involved in any kind of electronic commerce, whether they sell physical items, run dating sites, or help people find jobs. It also highlights that the nature of the threat is continuously evolving, and that companies need to use SDLC to continuously monitor and update their security.

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).