Blog item

Why security must be designed into software

Mar 18, 2021

MHR’s Engineering Manager Andy Jackson shares his thoughts on software and information security.

Andrew Jackson

MHR (formerly Midland HR) has been a Uniface customer for many years and continues to use Uniface to build its market-leading software for HR, talent management, payroll and business intelligence. Recently it has moved its solution from a client-server environment to a web-based and cloud-enabled one.

Uniface (U): We know you’re a keen advocate of good security practices. How would you summarize the message you’re aiming to spread?

Andy Jackson (AJ): My main message is about addressing security as early as possible, and certainly long before any issues get into a live environment. “Security by design”[1] is how I’d sum it up. Although issues can be detected with static analysis, or through penetration testing, it’s cheaper and better to stop them from getting into the code in the first place. For developers, this requires knowledge of your software and how it’s used, and also awareness of what can go wrong, including possible issues such as cross-site scripting.

U: What’s the best way for an organization to make all this happen?

AJ: Training your developers is the best way to assure code quality, and the training needs to be continuously updated. Above all, it’s a question of getting into good habits, such as running software as early as possible to check for flaws. After that, resources like OWASP [Open Web Application Security Project] are good for keeping up to date with the latest threats. Organizations can also make snippets of standard code available to help developers avoid accidentally implementing errors.

U: It sounds as if quite a lot of training is needed.

AJ: It is, but the benefit to time and cost upfront far outweighs the time and costs to fix issues in production and the reputational damage suffered. Relying solely on external sources for security testing is very expensive! Security is hugely important to a software vendor like us. We’ve been focused on the whole topic for over fifteen years – much longer than most companies. In addition, customers and prospects always want to know about our security approach.

U: How does “security by design” work when you’re updating existing software rather than writing something new?

AJ: Suppose you’re moving software that was written for a client/server environment onto the web – something that my company has done and that many others are doing at the moment. You may be planning to reuse a lot of existing code, but you should still approach the project as if you were designing a brand-new application. Think about how the layers will communicate, and about how services can be used. Then think about how you can stop someone external from getting at your back-end services, and how you can make the whole application secure from day one. It’s a totally new situation and should be treated as one.

U: Yes, moving code from a client/server environment to the web can introduce threats that the code doesn’t address because they didn’t even exist when it was written…

AJ: One example is that if you ever export data into CSVs, it may be possible for someone to write macros into a field and then run them in a spreadsheet. If your system allows an input field to start with certain characters, that field could be used to wipe out the whole system. Once you know about that possibility, you can make sure that any data fields that can be exported don’t begin with those characters. (But when you add that validation, you also have to think about any impact on existing users who may allow fields to start with those characters for legitimate reasons.)

U: How helpful are automated tools for finding potential security issues?

AJ: For Java, JavaScript, C+ and so on, there are commercial static analysis tools that can be helpful up to a point. Similarly, there are automated testing tools that will go through your website and find things like cross-site scripting issues. However, you can’t rely on these tools alone. For one thing, they will often generate a lot of false positives – you might be told you have 20,000 errors in a piece of code, but in fact, only a few of those are liable to cause problems in live running. At that point, it’s often worth hiring a security testing professional to find out which areas do need to be addressed.

U: What would be an example of a false positive?

AJ: In some cases, the errors will only allow you to do something that you can already do. Perhaps you could use reflected cross-site scripting to capture your own password, which you already know. Or perhaps you could delete your C drive, but only if you already have admin rights. Neither of those is likely to cause a problem in practice. You can also ensure strong operational procedures and implementation of best practice to minimize any impact.

U: Apart from understanding the threats that running old software in a new environment can create, what else should developers be aware of when moving to the web and (typically) a cloud environment?

AJ: They need to understand best practice in a range of areas like session and cookie management. Resources like are a big help but, again, developers will probably benefit from some training in the basic concepts.

U: What advice would you give to organizations that are creating new software, as opposed to updating or migrating existing software?

AJ: A lot of the advice is the same: Train your developers to be aware of security issues from the outset, use the tools that are available to help, and test for security loopholes. But in addition, you can take advantage of the security features that newer development environments offer. For example, Uniface DSPs will, out of the box, help secure your site against SQL, HTML and JavaScript injection, amongst other common attack patterns for hackers.

U: Do GDPR and similar data protection regulations make additional demands on software developers?

AJ: These changes have highlighted the fact that you should always be thinking about why you are processing a particular piece of data, what rules and controls apply, and what you can do with the data. If you’re working on a payroll system, it’s clear what basic data you must hold in order to pay people: Opting in isn’t necessary. But you might also hold additional data such as someone’s measurements for uniform, and then you have to consider separately how that can be used and what controls apply. You also need to think about retention and any related legal requirements: Payroll data may have to be retained for six years for tax purposes; builders working with asbestos may need to retain data for far longer. In other cases, you may need to agree on retention rules with the individuals concerned: An unsuccessful job applicant might agree to have their data kept on file to match with other vacancies, for example. You also have to support subject access requests. Under GDPR, anyone can request disclosure of the data held about them, so existing software should have been updated to make it easy for users to respond to these requests. For us, that wasn’t a big programming job, but the design certainly needed some thought.

U: So how does all this affect ongoing software development?

AJ: Data protection and information security is something you should consider every time you add new functionality to your software, and like other aspects of security it should be designed in from the outset. You also need to think about this when you make changes: For example, every time you add a new type of data to your system, you need to make sure it’s included in responses to subject access requests. This is a general point to realize about security: It’s not a “one and done” thing – you have to think about it every time you make a change to your system, and also be aware of ongoing regulatory and environmental change.

U: Encryption might be an example of a topic that’s constantly evolving?

AJ: Yes, it’s vital to stay abreast of the latest techniques and standards in that area. As machines and software get more powerful, decryption gets easier – for example, hackers can now easily run apps on GPUs to decrypt passwords by brute force. So you need to keep updating your encryption methods to make life as difficult as possible for hackers, while ensuring that users can still use the system, of course. My company enhanced our encryption methods recently, even though our existing ones were pretty good. At the same time, we took the opportunity to build in some tools that will make it very easy for us to enhance them again in the future.

U: At Uniface, we take the view that each layer of protection may fail, so there needs to be another one behind it. Do you agree we should work on the assumption that hackers will succeed in breaching our defences sooner or later?

AJ: Yes, you should aim to make anyone who does get on to your system decide that it’s just too much trouble to go any further. Definitely ensure that all your data is encrypted. Encryption should be enabled in the database; helpfully, database encryption works transparently with Uniface. If you use a package, check your supplier has taken care of this aspect.

U: Thank you very much for your advice. What would you say to anyone who feels intimidated by the security challenge?

AJ: I always come back to the slogan “security by design.” Think about this aspect of design at the beginning of every project and continually review it throughout the project. If you approach the topic this way, it’s not as scary as it sounds.

Uniface Safeguards mission-critical applications from the outset.

Read more about the 10 reasons why Uniface should be on your team.