The weakest link in my security experience is application security. It never mattered a lot, because I always had someone working for me who had the experience I lacked. That all changed when I came to a new state agency, though. For the first time, I have no one who can make up for my shortfall in this area.
We outsource our major information systems. However, we are going to start developing some internal applications. That makes me nervous. Our outsourcing vendor is contractually obliged to protect confidential information, something that is vitally important for the agency. When we start doing our own programming, how will I be able to ensure that secure coding methods are being followed? It’s time once again to educate myself.
Back when I was in the private sector and working in information security in the financial industry, we approached application security by sitting in on the meetings of the application development team. We might not have understood everything that was said about the actual coding, but we were able to advise the team on things like server and network architecture.
In the private sector, we always had a lot of people to work on problems, and each person could become specialised. Here, I wear a lot of hats. One of my responsibilities is preparing us for internal audits. So, what’s the auditor’s view of application security? According to guidelines published by the Information Systems Audit and Control Association, “The purpose of an application systems review is to identify, document, test and evaluate the controls over an application that are implemented by an organisation to achieve relevant control objectives. These control objectives can be categorised in control objectives over the system and the related data.”
The first two on that list, effectiveness and efficiency, aren’t big concerns right now. I need to focus on confidentiality, integrity and compliance. We’ll be handling confidential health information with our new applications. Compliance with the Health Insurance Portability and Accountability Act is serious business, and there’s a lot of potential for inadvertent exposure of protected information if we put these applications on the web.
Here’s what I knew at the outset: we are standardising on Java, a supposedly secure programming language, and we have hired a contractor to write applications for us.
It is my job to make sure that our networked computing environment is secure. That means sticking my nose into the programmer’s world from time to time. My interference is not always appreciated, but that’s not my concern. Knowing what I’m talking about is.
Needing to learn more, I stumbled around on the web for a while until I came across Sun Microsystems’ Java website, which has tutorials on practically every Java topic you can think of. I was delighted to find a section devoted to Java security. I am wading through the documentation, and I have learned that security is indeed built into the programming language. An application itself does not need to have security implemented, since you can request security services from Java — the language includes a set of application programming interfaces that provide security services, algorithms, methods and protocols. This allows the programmer to focus on the application itself, since security services can be integrated almost automatically. There’s no need to write complex security code.
The Java Security Manager can protect an application from unintended or malevolent programs, control access to resources, generate and check digital signatures and incorporate cryptography. All I want to know is whether someone or something could gain unauthorised access to resources or our data.
That leads us to authentication — determining the identity of a user. Java supports not only the Kerberos protocol and LDAP authentication, but also the establishment of a secure communication channel between the application server and the database server or the end user. I’ve always been uncomfortable with transmitting our data across the state network, which I consider to be “untrusted”. My first exposure to the workings of Java has raised my comfort level a bit.
I am feeling somewhat more knowledgeable, and there’s also something to be said for beginning to understand how much I have yet to learn about secure coding. Fortunately, I have a boss who does understand application development and is a programmer.
The author is a real security manager, whose name and employer have been disguised for obvious reasons