Acting as a Liaison to Help Develop Secure Web Applications

A challenge that has developed in our work with US federal clients is taking a system that we develop here at RTI through the certification and accreditation (C&A) process and receiving an Authority to Operate (ATO). To date, we have at least 1t systems that have undergone C&A. One of my early learning experiences was working with the US Department of Homeland Security on a moderate impact web application that was developed and hosted at RTI. In this experience, I learned to act as an effective liaison between our development group and the DHS directorate’s security office.

As a member of our software quality assurance group, I was drafted into the development effort to help research and respond to DHS information requests. Gradually, I learned more about the system and the process and was allowed to take on more responsibility liaising with the client, eventually becoming the information system security officer (ISSO). Also, as our clients increased their security awareness and the demand for security experience increased, I became the “security guru” for multiple projects across multiple clients that include SAMHSA and CDC.

In graduate school, I taught literature and writing, and conducted my own research. I translated this experience to help development teams document their systems and to learn and apply the C&A fundamentals quickly. As an ISSO, I implemented processes to develop and maintain documentation and helped develop and maintain excellent communications between our development team and our client. One aspect of these communications was becoming the point of contact through which most communications were funneled. This allowed me to respond if I had the necessary information, or contact the appropriate person and gather information as needed.

We were able to meet our overall goals of hosting a successful, operating website in a secure environment, maintaining all applicable security standards, and meeting the client’s expectations and requirements.

Part of meeting these goals meant responding quickly to our client’s requests. We provided all information as requested, operated transparently (i.e., open and above-board communication), asked questions in a clear and respectful manner, and maintained civility in all our interactions.

It also meant operating in as proactively as possible. In addition to addressing client requests, we maintained a shared drive in which we placed all new documents and maintained archives that required regular updates and maintenance. Documents included the system security plan, the contingency plan, the incident response plan, and change control requests and documentation, among others.

Updated documentation was crucial for our first recertification effort. The client examined artifacts carefully. Due to the diligence of the project team, we were able to assemble a package that gave us recertification with only five minimal Plan of Action and Milestones (POAM) items to correct.

Other process examples include working with our IT system administrators to develop a plan to implement the required DHS Windows Hardening Guidelines. With nearly 220 items on the checklist, we devised logical groups, and then implemented and tested items.

I also serve as a filter for feedback from clients to our project team members and for communicating back to the client to help clarify issues. For example, our project developer might have a question about how the client wants a NIST control implemented. I contact the client ISSO and gather information.

Process and learning pay off. When our system was selected for an Independent Verification and Validation (IV&V), we were well-equipped with documentation and processes.

Craig R. Hollingsworth, CISA
ISSO, RTI

[ISACA Now Blog]