Do you development software or applications internally?
Support for internally developed applications can allow speed to market, customization, and even a competitive advantage.
Common problems are supportability, security, and standardization.
If this sounds familiar to you here are four questions that you can ask your development team to help get a wrangle on the risk.
1. Have they standardized their application code repository?
The worse case is they have not standardized yet and application development is being done on the endpoint. Each developer is responsible for their own code, no central storage, and if it’s lost it’s gone forever.
The next worse case is it’s being stored on supported server infrastructure. This removes the ‘availability’ risk, but we often see this introduces an ‘integrity’ risk. This means the there is a risk of the code being changed and tampered with. This is because often times central server shares have too many rights assigned to them, and there are not sufficient security controls to map ‘who done it’ when it comes to code changes.
One step towards maturity is using an application control repository. An example is Jenkins.
The current trend is to leverage a cloud solution. This allows developers easier and quicker access to the code but comes at the cost of prolific accessibility.
When using a cloud solution, like GitHub, we recommend you place the following controls:
1. Two-factor authentication is required. A solution like Google Authenticator is a free solution.
2. Prohibit the storage of any credentials.
3. Require unique access assigned to specific people (no generic accounts).
4. Log access or at least have a governance process to regularly check the access and review controls.
2. How is access provisioned to application code storage?
As mentioned above, a very common security issue is having a ‘shared’ application development ‘ID’. The team shares this username and password to allow easier access to the code. The problem becomes:
1. Integrity
2. Rotation
The typical argument from the application team is that they don’t’ want to develop with their own ID, or they don’t have the proper rights, or they don’t want to receive all the alert logs to their production email account.
I get it. These are all valid arguments. But we can do better as security to equip them with a better way.
Some very quick ways I recommend (due to the brevity of this article):
* Create each developer a second ‘developer’ ID. I recommend marking the ID with a unique identifier to denote its purpose. (johndoe, and d-johndoe)
* Create a sandbox development environment like a VMWare virtual desktop or Citrix they can develop and test functionality.
3. Do they use production data in development?
My teeth always grind with anxiety when I ask this question.
I highly encourage you not to shame them for doing this but instead use it as an opportunity to have a conversation.
I’ve attempted to create policy against using production data in development, but I’ve found there are often special cases that ‘kind of’ justify it. This is either because the data is too costly to generate or the implementation time frame doesn’t allow.
From my experience, developers want to do the right thing but this ‘right thing’ is being dictated to them from above and is louder than the voice of security. So when they use production data, it’s often because they were told to, not because they choose to.
If this is the case for you and your business, use this conversation to build a process roadmap that communicates not to use production data in development unless required. If and when required, you won’t stop it, you’ll just ask for documentation so that you can provide a risk acceptance process to the driving party.
For more help developing a risk acceptance process please reach out to us.
4. How do they prevent credentials from being stored in the code? (Cloud storage).
This is an open-ended question and has more of a goal of getting an ‘attestation’ than a ‘right’ answer. Ideally, they will agree and commit to not storing credentials in the cloud. “HOW’ they do it should be up to them with security oversight and regular review.
This is because different programming languages and development platforms have different techniques on how to accomplish this. This is outside the scope of this article. The take away is, get them to commit to good security and not store credentials in the cloud.
Assign a controls governance task to the same security analyst that will be responsible for the regular ‘ID” review and other security checklists around application development security. Have them same popular spots for credential storage.
For example, if developing on Docker, have them check the ‘YML’ files.
Conclusion
Internally development applications can have advantages. Take time to build the appropriate security controls to reduce the risks to the organization.
With a solid security policy and regular straightforward conversations with the development team, huge steps can be made to reduce the overall risk.
If you want more help reviewing your application security or development lifecycle please contact me to schedule a conversation.
Download our FREE Secure App / Dev PDF Checklist:
Recent Comments