Reckless or Riskless: Another IBM i App Dev Expert Talks Security
February 7, 2018 Dan Burger
Security at the application level was the topic of an article in the Monday edition of The Four Hundred. Subject matter experts Brendan Kay, Alex Roytman, Robin Tatam, and Jon Paris provided insights and advice on the topic, which should be part of every organization’s overall security strategy. An additional perspective, which just missed the deadline for the Monday story, is being added today. It comes from Paul Tuohy, who lives eight time zones east of me, making the deadline I gave him a wee bit tight.
Although this contribution stands on its own, when added to the insights published Monday, we believe the awareness of this topic certainly benefits from the comments made by all five experts.
Paul Tuohy
App Dev Expert
ComCon and System i Developer
Historically, application security was menu security. The thought process was that the only access to the data is through the programs; the only access to the programs is through the menus; so, secure the menus and you have secured the application.
Of course, this changed (a long, long time ago) with the introduction of tools such as Query/400 and data transfer that allowed users to go straight to the data.
Unfortunately, a lot of developers still think of security as something relating to menus. There is also the (mostly false) perception that security gets in the way of development.
In reality, after a security policy has been put in place for an application, it has little or no impact on the day-to-day work of the developer of modern applications. Modern applications are tiered applications. This means security considerations are applicable in very specific places. This is very different from traditional monolithic programs that did everything and the same logic was applied in multiple programs.
A security policy provides the rules that programmers must follow when writing certain types of programs/procedures (database access for instance). This is not unique to security. Most shops have programming standards that range from coding styles to how to handle record locking. Security is one more standard to apply.
It’s an important requirement that checks are being made to ensure standards (security or otherwise) are being maintained. This can be done through code reviews and/or exit programs in a change management system that will validate code as it is being checked in.
The key is that the security policy has to be in place and all developers need to understand it and the confines they are working under.
The IBM i offers a plethora of security options and means of implementing security–from the generic library security, through adopted authority, to the granular row/column authority in the database. At the outset, someone must determine the best use of these application security tools. Developers then develop to that design. For instance, if row/column security is being implemented, developers must be aware that their programs may have to handle corresponding security violations.
Of course, a modern system (the more modern the better) makes it easier it is to implement a security policy. A modern application would have a single database layer, which means only one place where security has to be implemented. Compare that to historical applications where a table may be accessed in multiple programs and secured in each program. This is why I say modern design architecture lends itself to easy security implementation, but is has to be part of the design.
Developers should be aware of security pitfalls and those dangers should be part of the security policy. SQL injection attacks are one of the items a programmer might need to keep in mind.
In a nutshell, security is part of the design of the application. Standards determine how the security considerations are implemented in the code and developers code to those standards. Adherence to the standards should be part of the application security process
But the best security application level is one that requires the minimum of dependence on the developers. I am a developer – and I don’t trust them!
Reader feedback on these insights can be emailed to IT Jungle.
RELATED STORIES
Reckless or Riskless: IBM i App Dev Experts Talk Security
Testing For Security Inadequacies
Developers Can Improve Security and Reduce the Administrative Cost of Security
