Security Risks Avoided By The Development Team
February 9, 2015 Dan Burger
|
Some ideas need to be told and retold before the concept is fully grasped and action results. This isn’t the first time outspoken IBM i security expert Pat Botz has warned developers about dangerous security assumptions. This advice comes periodically, and it demonstrates how people hear without listening. That’s maybe a bit too harsh because there are indications it’s become more widely recognized that programmers have a role in data security at the application level. “You can’t secure a system these days without the programmers knowing about security,” Botz says. “Programmers can’t write programs that make data available to anyone who signs onto the system.” It’s not that they are unable to write that type of program. They most definitely can and do. The point of what he’s saying is that it can’t go on without some very bad consequences occurring. If it keeps on raining, the levee gonna break. Consequences such as significant data breaches, loss of personal information for possibly millions of people, a punitive fines that reach into the hundreds of millions of dollars should be incentive enough to address security issues where known weaknesses exist. I mentioned that this is becoming more widely recognized. That idea was put in my head by the folks at System i Developer. They surveyed their list of IBM i programmers who’ve attended the SiD’s twice annual RPG & DB2 Summit conferences and realized that security at the development level was a large concern. So Botz was brought in as a speaker at the upcoming event in Dallas, Texas, next month. He’ll do three sessions. Botz is a former IBMer and one-time security architect for the AS/400 and its successor platforms. “Our survey pointed to some specific additions to our current curriculum that could help attendees fill in the gaps on important projects,” explains Susan Gantner, one of the founding partners of System i Developer. “For example, as the information security landscape becomes more complex, developers are more impacted by–and more responsible for–data security and compliance requirements. We felt we could provide stronger guidance in those areas at the Summit.” In my conversation last week with Botz, the security consultant explained that the problem was not so much a lack of recognition that security is a development issue (the survey provided evidence of that), but that developers were eager to learn the best ways of dealing with it. As a starting point, Botz suggests developers take into account the reality of multiple IT roles. “Most of the time there is more than one application running on a system. Multiple people are using the system at the same time. When system users have read, change, or all authority, all the data becomes available to all the people, which means there are people without authority seeing data,” Botz says. “If developers allow all public authority, then anyone who signs on the system has access to the programs. And often that person has change authority.” Developers should learn how security and access control works. There are programming techniques to create authority levels. They are not normally something a system administrator can do. Programmers often assume the system administrator can control application security and that those who have access to the program have the proper authority, or they can get the proper authority. So programs are written to assume all access has been granted. When security breaches happen, it makes big news, but the inside details of how it happened are seldom publicly revealed. In one of the high profile breaches involving a large retail chain, Botz latched onto some information that he uses to illustrate his program security warning. The “who” is not important to this story. It’s the “what happened” that is pertinent. “We know the attackers got the authority of a vendor that was permitted to submit invoices to the retailer’s systems,” Botz says, and adds that it was unknown if it was an IBM i system, but Botz thinks it was not. “As soon as I heard that, I said to myself, ‘How the hell does a user ID that’s supposed to be used for submitting invoices give access to the source code for a credit card reader? That sounds like *PUBLIC authority (public access) to me.’ I don’t know if that was the case. But we would never hear that a machine was configured so that anybody who signed on had that kind of authority.” A few tips from Botz:
There are other techniques used to clean up programs with security risks, but the details go beyond the scope of this article. You’ll find more on this topic in the Related Stories list at the end of this article. Another recommendation is to use the search tool on the IT Jungle website with the keyword *PUBLIC. That will lead to more articles on this topic. Or contact the author at www.botzandassociates.com, if you want to discuss this with the expert. RELATED STORIES Limited Capabilities Workaround Heartbleed Postmortem: Time to Rethink Open Source Security? IBM i 7.2 Tightens Data Access And Security
|
