 | |||||||||||||
| |||||||||||||
Friday, November 11, 2016
time software vendor HelpSystems thinks the future still looks promising for the
Tuesday, September 13, 2016
The IBMer Who Decoded Bernie Madoff's RPG
The IBMer Who Decoded Bernie Madoff's RPG
Published: September 12, 2016
Published: September 12, 2016
by Alex Woodie
When Bernie Madoff's massive Ponzi scheme collapsed in 2008, erasing $65 billion in supposed wealth, the midrange community was somewhat surprised to learn that an AS/400 was at the heart of the operation. Soon thereafter, FBI agents called Rochester, Minnesota, with a request for IBM: Give us an expert witness who can untangle the ancient RPG II code and explain how it works to a jury. That job eventually fell to longtime IBMer Rich Diedrich.
Diedrich had worked in Lab Services since the early 1990s, back when it was called the Custom Technology Center. While Diedrich has expertise in many areas, including cryptography, it was his knowledge of System/36-era code that got the 29-year IBM veteran the job as the federal prosecutor's expert witness in the trial of Madoff employees Jerry O'Hara and George Perez.
"I have enough gray hair that I could understand the old RPG II code," Diedrich tells IT Jungle. "I was the highest-level application person in Lab Services that did AS/400 kinds of things, as it was referred to throughout the trial."
In August 2010, federal prosecutors working in U.S. Attorney Preet Bharara's office asked Diedrich to fly to New York for a meeting. "I met with the FBI and DOJ lawyers, and basically they showed me some of the code, ask me to look at it, tell them what I saw, and if I wanted to be the witness," Diedrich says.
Diedrich had never been an expert witness in any trial, and wasn't sure what it would entail. Working in Lab Services, he was used to dealing with clients who were clear in what they wanted. The federal attorneys, on the other hand, were cryptic about what they wanted from Diedrich, who had to remain unbiased and objective.
"The DOJ attorneys and FBI didn't tell me what to look for," he says. "They just said, here's the case, you tell us what you want."
Despite the open nature of the request, he agreed to take the job. While Diedrich would spend months deciphering the RPG and OCL code that ran Madoff's Ponzi scheme, he would not receive any additional compensation for the work. The contract between the federal lawyers and IBM gave Diedrich a degree of independence, which the task required.
Random Number Generators
The first time Diedrich took a look at the code for the feds, a few things immediately stood out. For starters, the RPG II code, which dates back to the 1970s, was in surprisingly good shape.
"It really wasn't badly structured, given what it was," Diedrich says. "There were a few things that caught my eye when I was glancing through it, like random number generators in the code that looked a little suspicious."
As Diedrich dug deeper into the RPG II and OCL code, he realized he would need some assistance to reverse engineer two key the programs, which totaled about 2,000 lines of code. "I looked at some of the normal code analysis tools, but none of them did exactly what I wanted them to do," he says. "Given that it was RPG II, OCL stuff, it made it a little trickier to use any of the standard tooling to do the reverse engineering that we needed done."
Finding nothing on the open market suitable for the 40-year-old syntax, he did what any normal IBM i programmer would do: he built the tools himself. "I actually wrote code that parsed the OCL to figure out what was called from where," he says. Then he built a slew of static Web pages that he could use to show the jury how the programs worked.
At the end of the day, he documented how the Madoff code worked using about 20,000 HTML pages. He would eventually use a fraction of these when he testified on the stand in late 2013, when the trial finally began.
A House Divided
As the DOJ's expert witness, Diedrich was asked to understand everything there was to know about the programs Madoff ran on the AS/400. (It's unclear what actual models Madoff used at the time of his arrest in 2008, but it's generally accepted that they were vintage, AS/400-era machines running OS/400 version 5.)
Diedrich was actually asked to analyze programs running on two separate AS/400 used at Bernard Madoff Investment Securities: One from "House 17," which generated reports for the fake trades involved in the Ponzi scheme, and another from "House 5," which did legitimate trading activities.
"House 17 was a fully separate system and it didn't talk to any other computer. It didn't do trades. It just printed out reports that looked like it was doing trading," Diedrich says. "They had written code that basically back-generated the trade. You could end a trade up to two years before whatever the current date was, which makes it much easier to have profits on paper."
When Diedrich used his tools to analyze the House 5 system, he didn't find anything suspicious. The programmers involved in running that system were never charged.
Code Was 'Nicely Commented'
While the reports generated by the House 17 system fooled Madoff's clients for years, it would take a little more work to pull the wool over the Securities and Exchange Commission (SEC). As Diedrich discovered, Madoff's programmers spent a lot of time preparing the House 17 operation to pass SEC audits.
"For the audit, they needed to have counter-trade trades. You needed to have who you were buying from, who you were selling from, the blocks you were buying and selling," he explains. "They had to essentially create all the documentation for the trades. So they had a program that would go out and essentially take a trade and then split it into sub-trades, and then it would go through and generate all the reports of all the trading tickets. They could print them all out."
Madoff not only fooled the SEC this way, but he fooled other banks that invested into his Ponzi scheme. In fact, the programmers used the same code for all audits, but changed the names of trading partners depending on who was doing the audit.
The Madoff programmers, Perez and O'Hara, were tasked with keeping track of all these changes and keeping everything straight, lest the whole house of cards come falling down. So the pair resorted to what any normal RPG programmers would do: They added comments to the code.
"The programmers nicely commented the code, which made explaining some things easier, because they said this is what they're doing," Diedrich says. "The jury didn't have to try to read the code. They said 'This is how we're generating these numbers.'"
Perez and O'Hara also added comments to ensure their audit preparation was up to snuff. "There were comments in the code hat indicated, for this kind of audit we need this kind of information," Diedrich says. "The code would say, 'We don't need this for this audit,' so they commented it out from the code at times, then they would put it back in for the other audits."
Fabricating transaction IDs posed a bit of a problem for the programmers, but they eventually rose to the challenge. As Diedrich explains, they came up with a creative method that was never spotted by auditors.
"One trick they used was they took the hundredth and the tenth digits from the transaction number, moved it over one spot, and subtracted it from the transaction number to get an earlier transaction number," Diedrich says. "That was one of the techniques they used to make up transaction numbers."
But how did Diedrich discover this method? "It was commented in the code!" he says. "Then they gave a simple example in the comment."
Growing Sophistication
As the Ponzi scheme wore on, and with more time on the saddle, Madoff's programmers got better at their jobs of fabricating an actual trading system, according to Diedrich.
"Over the years I could actually see how they had improved some of the random number generators," he says. "At first they used really simple ones. Then I could see where both programmers--in the same month actually--started using a more standard linear congruential random number generator. You could see the code being added. They got more sophisticated over the years."
Like most AS/400 shops, Madoff Securities protected its business by backing up data to tape. The FBI brought the backup tapes to Rochester for Diedrich to inspect, which gave him another view on how the code changed over the years.
"In April of 2006, they went through and deleted the special programs," including many starting with the letters SPCL. "They essentially wiped them all off the system. Something caused them to essentially delete all the special programs and some other programs on the system."
While it's not clear what caused somebody to delete the programs, that mere act actually helped Diedrich zero in on SPCL1K, which was the latest version of a key program used to perpetrate the massive fraud (the letter "K" represented the 11th version of that program). "It actually made it easier for me to figure out which programs to focus on," he says. "I'm going to be more interested in the ones that were deleted."
Conviction and Sentencing
In late 2013, after years of delays, the trial of Perez, O'Hara, and three other Madoff associates, including Daniel Bonventr, Anette Bongiorno, and Joann Crupi, finally began. Diedrich spent two-and-a-half days on the stand, including two days under direct examination by Bharara's prosecutors, and a half-day under cross examination by the defendant's attorneys. His testimony was limited to his analysis of the code maintained by the RPG programmers, Perez and O'Hara.
During cross examination, the defendant's attorneys asked Diedrich whether the programmers were just following orders, and if it was possible they didn't understand the scope of their actions.
"The impression I got was that the programmers understood the code, and that this is what it was doing, and what it was written to do," Diedrich says. "Random number generators and SEC audits indicate you're probably doing something wrong. You can be prosecuted for that, and these guys were."
Perez and O'Hara were found guilty for their role in the fraud, and were sentenced by U.S. District Judge Laura Taylor Swain to two-and-a-half years in prison, which was the minimum sentence. The prosecutors expressed dissatisfaction with the light sentence--it was even lighter than some defendant's attorneys had requested--but the judge was clearly swayed by defendants' position that they didn't understand the scope of what Madoff the mastermind was doing.
In any event, Diedrich found the experience worthwhile. "The whole thing was very interesting," says Diedrich, who has since retired from IBM. "It was a brand new experience for me. It was fun."
Diedrich is now working as an independent consultant with his company, Rich Diedrich Consulting, in Rochester. He's focusing a lot on application modernization, but don't ask him for help with System 36-era code. "I don't want to do RPG II anymore," he says. "I'm into the latest RPG and how do you use it effectively."
Diedrich will be sharing his experience as the DOJ's expert witness in the Madoff trial this fall at the COMMON Fall Conference scheduled to take place next month in Columbus, Ohio. His session, "RPG Programs Used by Madoff," will take place at 8 o'clock on the morning of Wednesday, October 26--the same day that O'Hara and Perez become eligible for early release.
RELATED STORIES
http://www.itjungle.com/tfh/tfh091216-story01.html
Thursday, August 18, 2016
Wednesday, August 17, 2016
The Unknown IBM i - An Amusing Tale From My Recent Travels.
Bob Losey
Certified IBM Advanced Business Partner at IBM POWER (iSeries/AS400) Specialist | IBM i (i5 OS/OS400) Specialist
Many of you may be old enough to remember the Gong Show and the “Unknown Comic” who wore a paper bag over his head. You could not see his face, so you did not know who he really was. That was part of the gag.
I have a similar tale. Too bad the punchline of this real story is so true.
I recently traveled to Salt Lake City to visit four clients.
After checking in to my hotel, I drove to a nearby restaurant for dinner.
The restaurant had very friendly service. The mid-twenty year-old waitress shared with me that she had served overseas in the armed services. Now she was studying to get her MBA and someday wanted to start her own healthcare company. I was very excited for her.
Then she asked what I did for work.
“I work with technology. I work with users of a technology you may not have heard of … IBM i.”
Structured Query Language Integrated In OS
“What’s that?” she asked.
I asked, “Are you familiar with SQL?”
“Of course,” she said. “It is Structured Query Language. It’s used for managing a relational data base.”
I was impressed with her knowledge. I continued. “As you may know, with most SQLs such as MS SQL or Oracle, the application logic and operating system are separate.”
She acknowledged, “That’s right.” She had a good understanding of SQL and software.
I continued, “Imagine if SQL was integrated in the operating system.”
“Wow,” she said with surprise, “That’s possible?”
Imagine SQL In The Background
“Yes. And, imagine that the server could manage itself so it optimized the SQL database in the background, so you did not have to.”
“Wow. That’s also possible?”
Virus Free And Can’t Be Hacked
“Better still, the way the system is designed, unless you have the proper credential you cannot hack it and the system is virus free.”
“That’s really impressive,” she said.
“Now, imagine this system is very reliable. It does not ‘lock up’ or suffer ‘the blue screen of death’ like older versions of Windows.”
“I have never heard of anything like that.” She was intrigued.
Salt Lake City Clients With 70-200 Users, Only 1 IT Person Needed
“You told me you also work in a clinic with Windows and you have an IT staff of 5 for 50 users. My Salt Lake City clients have 70 to 200 users on this technology with 1 person managing the server,” I explained.
“That’s unbelievable. I have never heard of such a system. What is it?”
“It’s called IBM i. Also known as AS400 or iSeries.”
Never Heard Of It But Could Really Use It
“Cool. I wonder why I have never heard of it before. We could really use that at my clinic.”
Seems to me IBM i is like the Unknown Comic with the paper bag over his head. Seems like no one other than those who work with IBM i know what it is.
Unknown Until Known
Then, once they get it, they are amazed.
I have a similar tale. Too bad the punchline of this real story is so true.
I recently traveled to Salt Lake City to visit four clients.
After checking in to my hotel, I drove to a nearby restaurant for dinner.
The restaurant had very friendly service. The mid-twenty year-old waitress shared with me that she had served overseas in the armed services. Now she was studying to get her MBA and someday wanted to start her own healthcare company. I was very excited for her.
Then she asked what I did for work.
“I work with technology. I work with users of a technology you may not have heard of … IBM i.”
Structured Query Language Integrated In OS
“What’s that?” she asked.
I asked, “Are you familiar with SQL?”
“Of course,” she said. “It is Structured Query Language. It’s used for managing a relational data base.”
I was impressed with her knowledge. I continued. “As you may know, with most SQLs such as MS SQL or Oracle, the application logic and operating system are separate.”
She acknowledged, “That’s right.” She had a good understanding of SQL and software.
I continued, “Imagine if SQL was integrated in the operating system.”
“Wow,” she said with surprise, “That’s possible?”
Imagine SQL In The Background
“Yes. And, imagine that the server could manage itself so it optimized the SQL database in the background, so you did not have to.”
“Wow. That’s also possible?”
Virus Free And Can’t Be Hacked
“Better still, the way the system is designed, unless you have the proper credential you cannot hack it and the system is virus free.”
“That’s really impressive,” she said.
“Now, imagine this system is very reliable. It does not ‘lock up’ or suffer ‘the blue screen of death’ like older versions of Windows.”
“I have never heard of anything like that.” She was intrigued.
Salt Lake City Clients With 70-200 Users, Only 1 IT Person Needed
“You told me you also work in a clinic with Windows and you have an IT staff of 5 for 50 users. My Salt Lake City clients have 70 to 200 users on this technology with 1 person managing the server,” I explained.
“That’s unbelievable. I have never heard of such a system. What is it?”
“It’s called IBM i. Also known as AS400 or iSeries.”
Never Heard Of It But Could Really Use It
“Cool. I wonder why I have never heard of it before. We could really use that at my clinic.”
Seems to me IBM i is like the Unknown Comic with the paper bag over his head. Seems like no one other than those who work with IBM i know what it is.
Unknown Until Known
Then, once they get it, they are amazed.
Sunday, May 29, 2016
Townsend Brings Modern Crypto Capabilities To Legacy RPG Apps
Townsend Brings Modern Crypto Capabilities To Legacy RPG Apps
Published: May 18, 2016
by Alex Woodie
The field-level encryption capability that IBM introduced with IBM i 7.1 is a powerful tool for securing sensitive data. However, IBM i shops that have not modernized their legacy RPG applications with SQL access methods find it difficult to use. That should change with new technology coming out of Townsend Security this week at the COMMON conference in New Orleans.
The DB2 field procedure exit point that IBM launched in 2010 helped a lot of IBM i shops to encrypt their data on a field-level. The capability to encrypt pieces of sensitive data residing in particular parts of their DB2 for i databases, while leaving other pieces of data untouched, was a blessing to companies in retail, healthcare, and financial services industries struggling to comply with tough new security mandates.
However, the FieldProc came with a catch. While it worked just fine if your IBM i application accessed data via SQL calls, it didn't work quite so well for older RPG applications using native I/O methods to access the database. The FieldProc method proved especially troublesome for companies that organized their databases in a particular way--when they built column-level indexes for sensitive data.
Patrick Townsend, the CEO and founder of Townsend Security, explains the significance. "Many--perhaps most--IBM i customers have not been able to leverage FieldProc automatic encryption because of the inherent limitations in legacy RPG I/O," he tells IT Jungle via email. "Encrypted indexes just don't work as expected with the older I/O model."
IBM's path forward for these IBM i shops entails re-engineering RPG applications to use the SQL Query Engine (SQE). "But this means a huge investment for most IBM i customers that provides little in the way of business improvement," Townsend adds. "So most IBM i customers have been on the sidelines."
So Townsend decided to do something about it, using another relatively recent piece of IBM technology: Rational Open Access: RPG Edition, which is sometimes called OAR, ROAR, or RPG OA.
Wednesday, May 4, 2016
Open Source and IBM i
Open Source and IBM i
One of the big concerns that I hear from many customers is about finding development resources both today and into the future. So what are we at IBM i doing to address this problem?
Modern RPG
RPG has been the primary language for IBM i since day one. It was created back in the day when punch cards roamed the earth. It has always been super at transactional processing and tight integration with the database. While punch cards have long since gone extinct, the need for transactional processing to run a business has not. For more than a decade we have been in the process of re-inventing the RPG language. With the announce of IBM i 7.3, the default for RPG on IBM i is a very modern variety. With the delivery of full free format a few years ago, the RPG language took a significant step forward towards the modern developer. With the latest new update, one of the last remnants of the punch card has been removed. RPG no longer has the an 80 column restriction. This is a significant step forward as now by leveraging fully free format RPG and storing your source in the IFS you have the opportunity to leverage a number of open source tools directly as part of your RPG development.With fully free form support, embedded SQL, integrated XML processing and the latest in development tools with Rational Developer for i, you have the ability to leverage the skills of modern developers. You are no longer tied to only being able to hire an RPG Programmer. Modern developers can deal with many languages, and today’s RPG is no longer something that will be foreign to them.
PHP
PHP is our flag ship open source language on IBM i. We have had a great partnership with Zend over the years and we have huge numbers of IBM i customer that are leveraging PHP today to provide a modern front end to their business applications. We have many examples of customers that are innovating their business not just from a ‘pretty face’ perspective. By leveraging modern interfaces and moving the UI into the hands of the user, they are able to change business practices and in many cases save real money. With IBM i 7.3 we have updated the version of PHP that ships with the media and IBM i 7.3 supports the latest versions of PHP out of the box.A little over a year ago now, the IBM i development lab delivered the new open source LPO – 5733OPS. This is our new open source delivery vehicle for IBM i. It shipped with 15 options, all but option 1 being empty to start. Well, in the past 15 months, we have significantly increased the number of options that have content. With the 7.3 announcement we are now up to 8, yes 8 options with all sorts of exciting new toys. Not only have we delivered new languages, but we have also looked at the entire picture. What are the other tools, utilities, and applications that are required to make the open source ecosystem on IBM i work.
Languages
- Node.JS – Option 1 of 5733OPS contains the V0.1 stream for the Node.JS language. Additionally we included a tool kit built on our XML Service engine to provide access to your IBM i native objects and business logic. We also have included a SQL based database connector to allow quick, safe and secure access to your IBM i DB2 data. With all the interest in Node.JS from the community, this language continues to rapidly change and be enhanced. To ensure seamless upgrades from the old to the new, we are shipping the latest version of Node.JS V4 in option 4 of OPS. In addition to the new language support, we are also making significant updates to our database connector. As you may know, Node.JS is an asynchronous language. The original DB2 connector worked in a synchronous manner. Well, the new driver has been enhanced to provide an asynchronous connection as well. We are excited to see the potential that this new DB connector can provide to Node.JS applications.
- Python – Last year we shipped Python V3.0 in Option 2 of OPS. We were pretty excited, with the latest version of Python figuring that was the correct choice. Well, in the Python community there happens to be a pretty big split. The V3.0 and the 2.7 crowd. Seems to be a pretty even split. So, we are now shipping Python V2.7 in option 5 of OPS. In addition to the integrated tool kit and the database driver that is included in both Python options, we are adding a new piece to the puzzle. We are including dJango. What the heck is dJango you ask ? It is a Web framework for Python that can simplify your task when creating Web applications with Python.
Ecosystem
- GCC & CHROOT – The first piece to the ecosystem puzzles was something we delivered late last year. GCC is the standard open source complier that most all open source projects makes use of. On IBM i we have a C complier, works great actually, even optimized for the Power processor, it’s the XLC complier. But when the open source world uses GCC, often compiling code with a different complier can cause ‘interesting’ results. The CHROOT support is a way for you as, open source developers on IBM i, to create your own safe ‘sandbox’ for developing open source projects. You can update things in your environment and not effect the rest of the system.
- GIT – The next piece of the open source puzzle that was announced with 7.3 was the GIT runtime. Git is the engine that powers the source control management software used widely in the open source community. It is the engine that Powers GitHub. Now with Git on IBM i, you can create your own ‘on prem’ source control library that leverages the latest open source support. Not only can you use it for all your open source projects, with modern RPG where the source is located in the IFS, you can also leverage GIT to control your RPG projects! There is even a GIT plugin that fits in nicely to your RDi development environment. GIT is being delivered in Option 6 of OPS.
- Tools – Yea, I know, a real original name. But it is pretty descriptive. This option is intended to be a set of basic tools that every open source developer needs. Its going to start out pretty small, but I can see this growing over time as our IBM i community identifies additional ‘must have’ tools and utilities. The first to make the list are .zip and .unzip. Now we will have an easy to install .zip tool on IBM i!!! Just put on a PTF and you are done. Yea, we have been needing this one for a very long time. Additionally we are including the bash shell environment. These tools are being packaged in option 7 of OPS.
- Orion – sounds like we have been gazing at the stars. Orion is a web based development environment. It’s a modern editor for writing open source applications. It has plugins for Node, Python and other open source languages. Yea, I know many developers have just used their own favorite editor from the community, but we felt that it was just not an integrated solution without this key tool. The other thing about Orion on IBM i, we have included a basic RPG syntax verifier! Again, leveraging Modern RPG and storing your source in the IFS, you can actually leverage Orion for simple RPG program updates. Orion is not intended to be a full feature/function IDE like RDi, but it is great for doing those quick simple updates. Orion will be included in Option 8 of OPS.
As you can see, with the announce of our latest IBM i operating system level, the IBM i continues to transform itself, by re-inventing pieces to insure that our platform can be successful today and into the future.
Wednesday, March 16, 2016
Verizon Outlines Disturbing AS/400 Breach At Water District
Verizon Outlines Disturbing AS/400 Breach At Water District
Published: March 16, 2016
Published: March 16, 2016
by Alex Woodie
Cyber intruders who gained access to an AS/400 at a water district were able to manipulate the flow of chemicals into the public water supply, Verizon says in its latest Data Breach Digest. While customers served by the water district were not harmed, the episode shows the potential consequences of failure to properly secure critical systems in an increasingly connected world.
Verizon dedicated five pages to laying out the disturbing breach of a water district that it referred to as Kemuri Water Company (KWC), which is not a real name. The water district had first contacted Verizon's RISK Team to conduct a proactive assessment of its security system. KWC insisted it had never been compromised. However, after just a little probing, the RISK Team found evidence of an actual breach by a "hacktivist" group with ties to Syria.
According to details of the breach, the hacktivists first infiltrated KWC's systems by exploiting known security vulnerabilities in a Web-based payment server application that KWC had set up to allow customers to pay their bills and view water usage information. Unfortunately, that system was directly linked by cable to its backend "AS400" system. Making matters worse, the water district stored login credentials for the AS/400 on that front-end Web server, and the AS/400 was directly connected to the Internet.
KWC's aging AS/400 system (it was more than 10 years old, according to Verizon) served many purposes, as it does for most organizations that run the platform, which has gone through several name changes (iSeries, System i) and is now officially called IBM i for Power Systems by IBM. Among the applications are core financials, billing, and database containing personally identifiable information (PII) about customers.
SCADA Plot
The water district also used the AS/400 as a supervisory control and data acquisition (SCADA) system to directly control hundreds of programmable logic controllers (PLCs) that opened and closed valves that govern the flow of water and chemicals used to treat the water. Verizon's RISK Team found evidence that the hacktivists logged into this operational technology (OT) system and manipulated the valves controlling the flow of chemicals.
"It became clear that KWC management was aware of potential unauthorized access into the OT systems of the water district," Verizon says in its report. "More specifically, an unexplained pattern of valve and duct movements had occurred over the previous 60 days. These movements consisted of manipulating the PLCs that managed the amount of chemicals used to treat the water to make it safe to drink, as well as affecting the water flow rate, causing disruptions with water distribution."
The hackers also stole more than 2.5 million files that contained PII data, according to the report. There was no evidence that the data breach led to any fraudulent activity, Verizon says. That's not surprising, considering the hackers worked out of IP addresses that were used in previous hacktivist activities, the telco and IT giant says. "The typical semantic footprint of a hacktivist attack shows greater interest in denying and disrupting the victim's ability to conduct business than stealing information for financial gain," Verizon says in its report. "That was definitely the case here."
The bad news, of course, is that cyber criminals operating in the Middle East were able to release potentially dangerous chemicals into the public drinking water supply serving several counties in the United States. , KWC had systems in place to detect the chemical release and took immediate steps to fix the problem after being alerted to the problem.
"KWC's breach was serious and could have easily been more critical," Verizon says in its report. "If the threat actors had a little more time, and with a little more knowledge of the ICS/SCADA system, KWC and the local community could have suffered serious consequences."
Lessons Learned
From an IT and IBM i point of view, there are several lessons to be learned from the KWC breach. Some of the lessons are obvious, while others less so.
Among the basic lessons at play here are the need to apply patches and remediate known security vulnerabilities that affect Web applications. It's also not a good idea to store user names and passwords for critical systems like AS/400s in plain text on front-end Windows and Linux servers, or to expose backend servers like the AS/400 to the public Internet. This is the low-hanging fruit of IT security, but all too often, organizations continue to violate these basic tenets of security and rack up the "duh" moments by the dozen.
Having SCADA systems directly connected to front-end billing systems (as KWC had) is not a best practice, but is undoubtedly fairly common. Verizon also took KWC to task for employing a single administrator for the AS/400 system. While having duplicate hardware, software, and network connectivity is standard practice for many shops, having redundancy in personnel is also something worth considering.
But some of the other lessons from the KWC hack are not so obvious.
Not too long ago, OT systems such as SCADA were housed separate from IT systems, such as corporate networks and payment servers. That "air gap" served as a barrier to cyber snoopers and criminals. But as technology matured and data centers grew, organizations recognized there were benefits to grabbing more "real time" data from operational systems, and hence, that air gap disappeared. The problem is compounded by having IT administrators remotely manage OT systems over the Internet.
"This new technology can provide a false sense of security, as operating budgets do not take into account the time to support, maintain and operate the new technology--thus it becomes ineffective," Verizon concludes. "Threat actors have the upper hand when technology is not maintained and they develop ways to circumvent how it works. Continuous operational and security training, coupled with additional staff, are required to stay on the same level playing field as threat actors."
You can download a copy of the Verizon Breach Digest at www.verizonenterprise.com/verizon-insights/data-breach-digest/2016/.
Subscribe to:
Posts (Atom)