• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • 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:

    • Programmers should be trained to ask questions about database authority.
    • When the program command is changed, it changes the attributes of the program, but not the source code.
    • Not every program needs to adopt authority changes. One change in a program is all that is needed within a job. All programs running after the changed program will not need to be changed.
    • Set all programs to adopt authority and then set data to public exclude. That way the people who come in via ODBC won’t have authority to it.

    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

    Low Risk Authority Changes

    Limited Capabilities Workaround

    Re-Adopt Authority Utility

    Heartbleed Postmortem: Time to Rethink Open Source Security?

    IBM i 7.2 Tightens Data Access And Security

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    Raz-Lee Security

    With COVID-19 wreaking havoc, cybercriminals are taking advantage of the global impact that it has had on our families, our businesses and our societies. It is more important now than ever to ensure that IT systems are protected, so that when all of this is behind us, we can get back to business as usual as quickly as possible.

    iSecurity Anti-Ransomware protects organizations against ransomware attacks and other kinds of malware that may access and change business-critical data on your IBM i. It even protects against zero-day attacks. Anti-Viruses can only report on the damage an attack has caused, but not stop it.

    iSecurity Anti-Ransomware has been recently enhanced with a Self-Test feature that allows you to simulate a ransomware attack on your IBM i. The simulated attack is limited to the test folder and cannot harm any other folders or files. This new feature lets organizations see how they are protected against known or unknown ransomware.

    Key Features:

    • Real-time scanning for known and unknown ransomware threats.
    • Blocks and disconnects the intruder.
    • Instantaneously sends alerts to SIEM as well as the offending computer.
    • Self-Test for attack simulation
    • Classification of the attack based on log.
    • Automatic updates with the most current ransomware definitions.

    Contact us at https://www.razlee.com/anti-ransomware

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Sponsored Links

    Northeast User Groups Conference:  25th Annual Conference, March 30 - April 1, Framingham, MA
    Profound Logic Software:  Reach Your Modernization Goals. Register for the February 25 Webinar now!
    System i Developer:  Upgrade your skills at the RPG & DB2 Summit in Dallas, March 17-19

    Infor Cloud EDI . . . DocOrigin Replaces JetForm . . . Empowered with Web Services . . . Create Excel Spreadsheets From DB2 Data With PHPExcel

    Leave a Reply Cancel reply

Volume 25, Number 07 -- February 9, 2015
THIS ISSUE SPONSORED BY:

ARCAD Software
ProData Computer Services
Computer Keyes
COMMON
Manta Technologies

Table of Contents

  • Surrounding The IBM i
  • German Hotel Search Engine Mashes Up Watson And IBM i
  • Security Risks Avoided By The Development Team
  • IBM’s Licensing Practices Under Scrutiny
  • IBM Layoffs Not As Dramatic As Rumored

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Power10 Entry Machines: The Power S1024 And Power L1024
  • Thoroughly Modern: Latest IT Trends – Bring Security, Speed, And Consistency To IT With Automation
  • Big Blue Unveils New Scalable VTL For IBM i
  • As I See It: Thank God It’s Thursday
  • IBM i PTF Guide, Volume 24, Number 32
  • JD Edwards Customers Face Support Decisions
  • Security, Automation, and Cloud Top Midrange IT Priorities, Study Says
  • Cleo and SrinSoft in Integration-Modernization Link Up
  • Four Hundred Monitor, August 3
  • IBM i PTF Guide, Volume 24, Number 31

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2022 IT Jungle

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.