Thursday, September 14, 2017

IBM i Technical Sales Manager at Software Engineering o…

With the increasing complexity of IT regulations such as SOX or HIPAA, it’s harder than ever for IBM i security managers to keep their business moving, while satisfying auditor requirements. To meet the need for a separation of duties, IT user profiles have become more restricted. These restrictions often slow down the ability of IT responders to resolve problems in an emergency, since the responder must first request access for higher authorities to perform the tasks that will solve the problem.
One of the greatest challenges of security management is reducing user authorities while still allowing the user to function properly. This challenge can be met by implementing a break glass strategy, which enables your IT department to solve problems faster, while meeting audit requirements and reducing the risk of a security breach.
A break glass strategy refers to having a method to temporarily grant IBM i access to the authority an IT user needs in an emergency, without the user having to wait for that authority to be reviewed and granted. It eliminates the needs for administrators to permanently give user profiles higher authority levels than what they really need day to day, a practice which increases a company’s risk of a security breach. Many vendors such as SEA with its iSecurity Authority on Demand product, offer software with break glass capabilities.
Without a break glass strategy, one of three things usually happens.

Your IT user profiles may permanently have authority levels that are higher than what they need on a daily basis, or:

IT personnel have to request access to or know the password for a shared high authority user profile such as QSECOFR for emergency response, or:

The IT user has to request and wait for their authority to be increased as the emergency is happening.

All of which are risky strategies. Having higher authority than really needed is just bad practice, and invites disaster. Granting higher authority on an emergency basis means you have to remember to take it away. Sharing a QSECOFR profile amongst the IT team is dangerous and doesn’t provide a real audit trail. You may have a formal process in place to track back who requested the access and compare that to the log files, but that can be a manual, time consuming procedure.
Break Glass solutions simplify the process of granting increased authority as needed and provide a complete audit trail and reports. The security manager provides IT personnel with PIN codes which will grant temporary authority to perform specific tasks. This is often achieved through the creation and use of service accounts, which the pin codes provide access to. Depending on the task that is being performed, the user can review a list of available accounts and authorities to choose from, and the user uses the pin code to unlock and use them. The security manager can be notified that someone is accessing a particular account and a complete audit trail of the tasks performed is kept.
A good break glass solution allows security managers to have control over the PIN process, including such basic items as how long will access be granted for, how many times the PIN can be used, and whether each user has a PIN or if they have to request it each time. It’s important to be able to implement the pin process in a way that will meet your specific security policies.
Auditors will want to know how many times your break glass strategy was used, by whom and why, because those events are the times in which your business was at the highest risk of having a security breach. Having reports readily available that can detail who requested increased authorities, who approved them, and what tasks were performed will save you a ton of time during your audit. With the reports generated from your break glass software, you won’t have to perform manual searches and compare your records with log files.
A break glass solution saves valuable time and resources in an emergency, enforces segregation of duties, and enables relevant personnel to obtain access to approved authorities as needed. Its real–time audit of access rights protects sensitive corporate assets and significantly reduces the number of profiles with powerful special authorities.

Thursday, August 24, 2017

Many customers ask us what can they do to insure their IBM i systems are in compliance before their auditors show up. Here are some ideas for pre-compliance audit checking that you can perform to get your systems in shape before an audit happens.Check the PCI DSS standard against your system, even if you’re not covered under PCI DSS
We’ve found that reviewing the Payment Card Industry (PCI) Data Security Standard (DSS) is one of the best things you can do to prepare your systems for an audit, even if you’re not covered under PCI DSS. Why? Because even though PCI DSS is geared towards credit card processing, it’s also an excellent source of common sense security configurations for protecting any type of confidential information.
Everybody has something that needs protection on their IBM i and their network…and PCI DSS provides a good template for what type of security should be in place. If you don’t have credit cards on your system, you probably have payroll information, engineering files, or customer databases that must be protected. Evaluating your shop against relevant PCI DSS standards can help you determine where potential IBM i and network weak spots are, including the PCI DSS standards on:

Reviewing the PCI DSS standard is a good exercise because unlike many of the other standards, PCI DSS is much more specific in describing the goals needed to secure your network. And many PCI DSS goals can be applied towards other types of auditing.Listen to your auditors and remember that compliance is an IBM i issue AND a network issue
Some auditors only want to audit your IBM i configurations. Other auditors need to look at both your IBM i configurations and the network infrastructure that information travels over. Check with your auditors to see which items are in scope, double-check your audit requirements checklist (if one is provided), and check previous audit reports (even if they were performed by different auditors) for audit points needing remediation.
If you find your network is considered within scope for an audit, make sure your network people are available and aware of any audit requirements they need to insure compliance. This is especially important in larger organizations where the network group and the IBM i support staff may reside in different departments or divisions.If you’ve been sold or merged….
If your company was recently sold or merged with another division, review any audit records (requirements, reports, remediation, and follow up) that your new auditors had previously issued for your new organization. Prior documentation can help you determine what new requirements you’ll have to implement to become compliant. Old audit material can provide hints on what your auditors care about and what they focused on in the past.Bring in an outside compliance evaluator
Several companies offer products and services that provide comprehensive evaluations of an organization’s IBM i compliance with PCI DSS, Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other government or industry regulations. Compliance evaluators can be a major help in maintaining compliance before, during, and after an audit.
As an example, SEA offers iSecurity Compliance Evaluator, which performs IBM i compliance checking for several common regulations. Compliance Evaluator can check your IBM i system and network activity against a common standard; report on unexpected changes in the environment; score your performance against self-defined compliance targets that you enter yourself; and send out full reports as well as non-compliance reports that only show your problem areas. Other compliance evaluation packages may offer different functions, but the idea is to pre-evaluate and report on your system using criteria provided by you and your auditor and then remediate any deficiencies the system may find before the audit occurs.Getting ready for the audit
These are only a few ideas for preparing your systems for an audit before the auditors show up. Please feel free to contact us at SEA software for more information and advice on how to prepare for your own audit situation.

Thursday, August 17, 2017

AS/400 is probably a term that tons of today’s young programmers haven’t even heard about.

I often run into different site’s, different surveys, like “What’s your favorite server operation system?”. Surprisingly (formerly) OS/400 (now IBM i) is not even on these lists anymore! I remember the times when the Operating System of the AS/400 was a huge hit!This short article is for the ones who don’t really know much about this topic, but as an open-minded professional, want to know a bit more about this old-school giant.

An Original IBM AS/400 hardware.

The operating system of the AS/400 has had different names… OS/400, or iSeries, etc… We like its original name, because “AS” stands for “Application System”. It describes well what is special in the system:
It is an Application-centric OS, NOT a processor-centric.
It is called IBM i now, but it was a long road…

The Brief History of the OS

First, there was the IBM System/38. It was a minicomputer for business and departmental use, launched in 1979.
It was a complete product line, with different architectures: System/3, System/32, System/34, System/36.
Later on IBM realized that compatibility is key for the thousands of programs written in legacy code: They released the AS/400 midrange computer line in 1988. The AS/400 was supplied with a proprietary operating system: OS/400, which enabled programs written for System/34 and 36 to be moved to the AS/400.
In 2000, the AS/400 was rebranded as the eServer iSeries.
Then in 2006, it was rebranded again as IBM System i.
2 years later, in 2008, the System i and System p product lines were combined into a new product line: IBM Power Systems.
The operating system was also rebranded from OS/400 to i5/OS and finally to IBM i.It IS an old system. But it is STILL widely used. Mostly where data safety and stability is above everything else. It is mostly used in banks, but often in manufacturing, transportation and logistics, finance, and so on…

What is unique about AS/400?

Why is it a big deal? How is it so different from other operating systems?Let’s look the short philosophy behind the different operation systems!Linux: There are a lot of small devices, apps, etc. for specific tasks, and then they “link” them together to do something bigger.Windows: Monumental target-programs (solutions) for a concrete problem. (See it mostly as a “package”).AS/400: A stable system, with an excellent documentation and fool-proof operations. Applications are good enough alone. They are not monumental and don’t need to link them together to make something useful out of them.

The operating system itself was object-orientated already from the beginning.

What does it mean?
Everything is an object and not a file!
For example, on Linux, everything is a file, even the devices, the printers, etc.AS400 has objects. The number of the object-types is almost 100, and the *FILE type that represents a database file of the built-in relational database is only one of them.Few other object types:
*DTAQ: Data queue (used to queue up data entries for communicating and distributing data between different jobs).
*DIR: Directory
*LIB: Library (where everything below, except directories and stream files, is stored; libraries cannot exist within other libraries)
*PGM: ProgramWhat kind of programming languages can you use on AS/400?
Programming languages available for the AS/400 include RPG, assembly language, C, C++, Pascal, Java, EGL, Perl, Smalltalk, COBOL, SQL, BASIC, PHP, PL/I, Python and REXX. Several CASE tools are available: CA Plex (formerly AllFusion Plex), Synon, IBM Rational Business Developer Extension, Accelerator, LANSA, Uniface and GeneXus.
And there is a complete layer called PASE to help to port anything from AIX to IBM i with minimal effort.

The topic of IBM i / AS/400 / OS/400, etc. is much deeper, we only have scratched the surface in this article.

Senior Developer (RPG, Cobol, Java, HTML)

Gabor has 20 years of experience in building large enterprise systems on the AS400 platform (RPG, Cobol) as well as in Java/J2EE/HTML. Gabor has experience in the banking and operating lease industries. Gabor is another mastermind on our team: he can understand and solve problems extremely fast and then can deliver very high-quality code. Other developers watch him working with awe. Gabor has an MsC (Programming Mathematician).

Data Protection: a taste of things to come (the world over)

Data Protection: a taste of things to come (the world over)

For reasons going back in history, the EU has established itself as pioneer in data protection legislation and 2016 is no exception.

In April 2016, after years of preparation, the new General Data Protection Regulation (GDPR) was adopted to harmonize patchwork directives across EU member states and safeguard the rights of citizens in the digital economy. It comes into effect on May 2018, and being a regulation rather than a directive, will apply regardless of any approbation by individual member states. Its noble goal has been to simplify the task of compliancy and ultimately reduce its cost. But the GDPR comes with amassive sting in its tail. According to a recent globalstudy, what 80% of IT professionals fail to recognize is the international reach of this EU regulation, and the eye-watering penalties of failing to comply.

Whether your organization is based in the US, UK or anywhere else in the world, insufficient provision for protecting EU citizen data runs the risk of fines of up to 20 million EUR or 4% of your turnover worldwide (whichever is higher).

Organizations can amass personal data on EU citizens unwittingly through common techniques such as profiling, loyalty cards, online shopping and the like. The final text of the GDPR even references “monitoring the behavior” of EU residents by tracking their digital activities. The GDPR cannot get much broader, given that nearly every website in the world does exactly that.

So what actually constitutes personal data, and how can you comply? Any data that pertains to a person’s online ids, credit card information, IBANs, any type of banking information, as well as health information, even location data and biometric/genetic data is considered personal. The GDPR requires that you take both organizational and technical precautions to prevent the transfer of data to a non-compliant body, prohibit use outside its intended purpose, and anonymize data where necessary. It also demands notification of a data breach within 72 hours (welcome news in the wake of the Yahoo debacle where it took nearly 2 years to disclose one of the biggest customer security breaches on record). Note to self: why not take a stand against Facebook’s attempt to share Whatsapp user data across its services, in direct contravention of its promise when it bought the app?

What is also new with the GDPR is the notion of “privacy by design and default”. In choosing to include these as key principles, the legislator has acknowledged that privacy cannot be ensured by means of legislation alone, but it must be incorporated in the design and maintenance of information systems. Under Article 25 of the GDPR, a data controller is required to implement protective measures both at the “time of determination of the means for processing, and at the time of the processing itself”. Such measures include data anonymization, pseudonymization or other privacy-enhancing technologies.

You might be forgiven for thinking that as a US or UK-based company who avoids soliciting EU business that data protection is not your problem. But there are many reasons to take it seriously.

Case Study #1 – USA

Take the U.S. for example. Although there is no single, comprehensive federal (national) law regulating the collection and use of personal data, each congressional term brings proposals to standardize laws at a federal level. A mixture of federal and state laws and regulations sometimes overlap, match and contradict one another. In addition, there are many guidelines, developed by governmental agencies and industry groups that do not have the force of law, but are part of self-regulatory guidelines and frameworks that are considered “best practices”. These have accountability and enforcement components that are increasingly being used as a tool for enforcement by regulators.

Yet attitudes to data privacy in the US and EU have historically been considered as polar opposites. EU attitudes towards data privacy, which favor the rights of the individual, contrast with those of the US under the US Patriot Act which favors the rights of the state. So how can we reconcile data privacy and public security in a world where terrorism is striking at the heart of our democracies? Wherever you stand in this debate, the impact of these regulations will be non-negligible.

Some of the most prominent US federal privacy laws include the Federal Trade Commission Act (FTC Act), Financial Services Modernization Act (Gramm-Leach-Bliley Act – GLB), Health Insurance Portability and Accountability Act (HIPAA), Security Breach Notification Rule, Fair Credit Reporting Act and the Fair and Accurate Credit Transactions Act, Electronic Communications Privacy Act and the Computer Fraud and Abuse Act. The president-elect has already said that with regard to cyber security, data retention, data transfer and compliance, some of the existing regulations will be changed, potentially even replaced with some new, stricter regulations.

So like it or not, data privacy is a force to be reckoned with in 2017. Compliance with the most stringent GDPR is a safety net in transatlantic business. The old “Safe Harbor” mechanism in the US has now been replaced by the “Privacy Shield”, effective from August 2016 and endorsed by the European Court of Justice. Any US company canself-certifyfor Privacy Shield to the Department of Commerce and publicly commit to comply with the Framework’s requirements. While joining the Privacy Shield Framework is voluntary, once an eligible organization makes the public commitment to comply with the Framework’s requirements, the commitment will become enforceable under US law. It is said that the new framework will underpin over $250bn of transatlantic trade in digital services annually by facilitating cross-border data transfers with the EU.

Case Study #2 – UK

Yes, but Brexit! More than likely, as it happens… But UK national laws already apply. Independently of the EU, all organizations in the UK that collect, process or store personal information must comply with the UK Data Protection Act 1998 (DPA), or face fines of up to £500,000 in the event of a data breach. And given that Brexit cannot actually come into effect before Spring 2019 (assuming Article 50 of the EU Lisbon treaty is triggered in March 2017), this leaves a full year in which GDPR punitive measures will apply to the UK just like in any other EU member state. And even post-Brexit, the “Great Repeal Bill”, intended to come into effect immediately on exit from the bloc, would directly incorporate all EU law into UK law. During an unspecified period it will then be possible to “amend, repeal or improve any law after appropriate scrutiny and debate”.

Whether Brexit culminates in something resembling a Norwegian or Swiss model, or a far less EU-friendly alternative – even the hardest Brexiteers would probably agree that instead of a freestyle deal, maintaining equivalent data protection regulations with the trading partner that consumes over 50% of your exports would not be such a bad idea. The Information Commissioner’s Office (ICO) states in basic terms: “if the UK wants to trade with the Single Market on equal terms we would have to prove ‘adequacy’ – in other words UK data protection standards would have to be equivalent to the EU’s General Data Protection Regulation framework starting in 2018.”

According to PwC, the new compliance journey will require organizations to map and classify all their personal data; perform risk assessments; design privacy protections into all new business operations and practices; employ dedicated data protection officers; monitor and audit compliance; and document everything they do with data. Clearly GDPR compliance will become a major advantage over rivals.

Case Study #3 – Tech companies and IT departments

One of the fundamental changes with the GDPR is that companies that provide services to other companies – known under the legal term of “data processors” – will also face the same hefty fines, which will affect technology service providers in particular.

An independentsurveyof large company CIOs showed that 52% of US companies possess data on EU citizens, making them subject to the GDPR. Primary concerns for these companies are the ability to know where customer data is at all times, andproper concealment of customer data used intesting. Interestingly, the vast majority of this customer data actually resides on back-end systems. In this context, test data privacy solutions will place a major role in compliance.

Other key findings from US respondents to this survey include:

83 percent use live customer data in test systems when testing applications, because they believe the use of live data ensures reliable testing and accurately represents their production environment

71 percent believe the emergence of mobile technologies is one factor making it more difficult to track customer data as it moves through the enterprise

The adoption of DevOps and agile approaches and their reliance on continuous testing actually increases the criticality of test data protection, as the pace and frequency of software rollout is increased.

With more modern 3-tier applications (particularly mobile) ultimately connecting through the back-end application, test data anonymization tools (such asDOT-Anonymizer, which is both platform and database agnostic) are an effective solution to mask sensitive customer data throughout the application testing process.

Olenka Van SchendelVP Business Development at ARCAD Software group

With 28 years of IT experience in both distributed systems and IBM i, Olenka started out in the Artificial Intelligence domain and natural language processing, working as software engineer developing principally on UNIX. She soon specialized in the development of integrated software tooling including compilers, debuggers and source code management systems. As VP Business Development in the ARCAD Software group, she continues her focus on Application Lifecycle Management (ALM) and DevOps tooling with a multi-platform perspective including IBM I.