Adam Stone, Contributing Writer
March 5, 2015
Mobile apps are poised to revolutionize the way the military conducts its operations. Soldiers armed with smart phones can direct artillery fire, conduct training in the field and chart critical topography.
Some apps come from commercial sources, others are crafted at the command level, while others are being developed ad hoc by soldiers in the field. Sooner or later, they all must be vetted in order to be officially incorporated into a soldier's toolkit.
For developers looking to produce a usable product, the Defense Advanced Research Projects Agency (DARPA) has supported the National Institute of Standards and Technology (NIST) in the development of a set of guidelines to create a compliant product. But the crucial element of the process comes from the Defense Information Systems Agency (DISA), which certifies the security of new apps.
Initial steps
To get an app through DISA's approvals process and be declared safe for deployment, the command of an app's potential user base puts in a formal request to the Device and Mobile Apps Branch of Mobility of the DoD Mobility Division. From there, the minutiae begins.
What is the operating system? Are there any associated costs? Is the app specific to a particular mission? And the security details begin early on. Will the app connect back to the mission environment, meaning will it be tapping into the user's network in order to access data?
Only after passing these initial hurdles does the actual evaluation even begin. "At this point we are primarily looking at the security within the apps," said David Sanfield, DISA's deputy portfolio manager for DoD Mobility.
That process of security assurance has gotten easier since 2014, at least for the testers. A rigid routine of 70 checks has been pared back to 20 consolidated security "profiles." Rather than examine test results by hand, the examinations are becoming increasingly automated.
"That is hugely important. Sometimes these results are readable, but sometimes it looks like a foreign language," said Nora Dillman, DISA's chief of systems and application engineering, DoD Mobility Program Management Office. Automation makes it much easier to sift through those sometimes inscrutable results.
How it works
Testing a new app doesn't include just looking for malicious codes, those secret passageways that bad actors can use to compromise a mission. Often, DISA examiners see things right out in the open that raise red flags.
Maybe an app is accessing email or calendars, or turning on a device's recorder. These may be acceptable behaviors, or not. "We want to get the whole picture, we want to get all the information," Dillman said. If it turns out these actions are necessary for the app to function, it may pass this phase. If not, back to the drawing board.
An app will most often flunk testing at this point if it makes connections abroad. "Something that is a proxy in a foreign country, an app that is sending data overseas, that is a concern," Dillman said. This is common in commercial apps, where developers may try to cut costs by hosting overseas.
In government apps mistakes caught at this stage typically often include sloppy coding or battery-draining functions, rather than anything more malicious.
Up the line
A report summing up all these findings goes up the line to an internal cybersecurity expert who makes a recommendation. Then a DISA field security office will review the reports again and possibly do additional testing. The whole process typically takes about 30 days before landing for sign-off on the desk of the Designated Approving Authority. Those who fail can try again.
While much of this sounds straightforward, security in the mobile world is a complex phenomenon, and the process of approving an app often requires a degree of finesse on the part of testers.
For example, while testers may not find any gaping holes in the code, they still want to understand the context in which an app will be used. "Someone has to say: It can specifically be used here, by this person, in this circumstance," Dillman said. The planned use of an app can help security testers determine whether its features could present any potential threat.
"When they initially request an app we will ask, 'Are you recommending this be an enterprise app or for limited distribution?' " Dillman said. "If they say enterprise, then from DISA's perspective we may not be comfortable with the risk [of certain functions], but if they tell us we can limit that distribution just to a specific user group, we may be more comfortable with that."
An app that makes it across the security Rubicon will be deemed fit for distribution in DISA's view. What is lacking in this process? Any examination of the app's functionality.
"We make sure it is safe and compatible with the environment, but it is up to the operational requestor to determine whether it is appropriate to that environment," Sanfield said. "Those who request it are the ones who are best able to determine that."
Charting workflow
In recent years NIST has developed and refined the apps development workflow through the DARPA-supported Transformative Apps program. As a part of that effort, NIST created a range of tools and processes to help shape an emerging app so that the outcome will be in alignment with various regulations.
In terms of specific development workflow, NIST has developed AppVet, an open-source Web service designed to help developers take all the necessary steps before submitting their product to a formal evaluation.
The idea is to give developers a set of tools that will help ensure everyone is working off the same page, explained NIST Computer Scientist Tom Karygiannis. So, for instance, NIST has laid out best practices for programming, generating libraries on known vulnerabilities. The workflow process also helps developers put in place the required elements to protect classified data. That's something DISA will be looking for, and while use of the NIST tools is not required, the availability of these predefined steps can be a boon to developers looking to streamline the approvals process.
At the end of the day, the NIST process encourages developers to run it by the people in the field. "Guys in the lab aren't going to think of certain things. No one knows their domain better than the guys who are using it," Karygiannis said.
No comments:
Post a Comment