When your company’s intellectual property is in jeopardy – the security action plan should be tougher than the norm. This article assumes that your company is planning to control the intellectual property of crown jewel business applications at offshore development centers.
Usually, for business owners, it makes sense to utilize Offshore Development Centers (ODC) for application development, the main drivers are:
- - Freeing up internal resources
- - Cost
- - Access to larger skill pools
- - Quality
- - Speed
- - Scalability etc.
But the benefits of ODC can easily be annihilated by a single incidence of loss of intellectual property. That is why "security" is the key catalyst in enabling offshore application development.
In order to prevent data loss at offshore development centers, several layers of security controls are needed.
The usual security statements from Offshore Development Centers are “We do use firewalls”, “We have SAS70” or “We have token based authentication” type of standalone security declarations when intellectual property security is questioned. Another common misunderstanding is that many ODCs confuse application security with securing intellectual property during development. Secure SDLC and Securing Offshore Application development are not the same.
Briefly, single layer of security controls are not good enough.Unless a structured solution framework with several layers of security is targeted, most ODC initiatives will end up with critical data loss.
The idea is simple: define risk, check vulnerabilities, deploy controls, check, and repeat.
The risk is not that complicated either: Without proper security controls in place, offshore application developers can walk away with intellectual property on a print out paper, USB token, DVD, photo snapshot etc (which is the application components in app dev) , or developers can “send” the intellectual property out via connected networks (wired, wireless, mobile etc).. And the applicability of legal enforcement may not be on your side when this happens (based on the offshore location that you plan to operate)
It makes sense to build the framework with
1-Technical Controls:
As discussed above a structured approach where several technical controls are weaved in layers are required. To begin with the following controls should be analyzed: Activity Monitoring, Logging, Alerting, User Management, Administrative Access Management, Access Control, Privilege Management, User Repositories, Data Rights Management, Separation of Development, Test, and Prod Environments, End Point Security, Port Security, Desktop and Session Virtualization, Kiosk and Jump Stations, Encryption, Wireless Security, Network Access Control and Network Based Security Controls. Technical Controls discussion will also include physical security controls framework. All controls will be discussed in defense in depth layers.
2-People Based Controls:
Analysis of Operating Country Legal Framework, Applicability of non-disclosure, non-competition and non-solicitation agreements, background checks, user awareness training for security, balancing security with productivity
3-Process Based Controls:
Audit Framework, Metrics and Measurement Framework, Secure Code - SDLC Frameworks/Best Practices, Information Security Frameworks, Best Practices for policy based controls, Governance Risk and Compliance (GRC) Frameworks
I will focus more on the technical layers – and leave people and process based controls discussions other posts.
Technical Controls
(The following areas should be checked and effective controls should be selected based on a logical analysis and prioritization)Layer 1 – Go back to onshore model:
The first technical security discussion is where application development will be. The first question should answer if the offshore application development process can take place on onshore systems..This may sound weird in an offshore app development discussion, but when you utilize remote terminal/session connections (Citrix, TN3270, RDP) or desktop virtualization solutions (VDI) ; moving application development back to onshore locations makes sense.
I strongly recommend moving the actual location of the application development environment back to onshore.
If you cannot do this, you need to build several new controls (basically replicate your enterprise down at the offshore development center). Desktop Security and secure data storage/with encryption become an important topic in local development if you choose to leverage offshore development systems. I will not cover this scenario. I will assume that you will choose hosted application development architecture (again Citrix, RDS/RDP, SSH/TN3270, VDI etc) ….
Layer 2 – Secure Client Access:
Even if you have no servers at offshore location, you will still need to secure environments that session clients run (Desktops, Terminals, Thin Clients etc); the first rule of thumb is to restrict/limit these access devices to a physical facility/perimeter that you control physical security. (Another layer). These clients should be centrally managed and they have to be read only for developers (since you use hosted desktops/sessions at your onshore systems for development). Make sure that you have all the monitoring to avoid firmware tampering/redirection/root kits. You will need sophisticated event monitoring on these systems. TPM, File Integrity monitoring, sophisticated change control are the first few steps to start. BIOS security and local superusers should require top secret clearance for modification. Administrative access to these systems “must go through a jump server, preferably after strong authentication.
Layer 3- Make sure that the physical perimeter exists:
Physical security must be managed and monitored. A good policy is the restrict “any” mobile access to development areas. Just leave all cell phones, smart phones, and iPads etc, before the security check point prior to entering the secure application development area, I do understand there are always ways to bypass these controls, but a stricter policy enforced by scanners is a good start. Usually a mix of x-ray+ walk through security checkpoints work. Guarded ones are always better. Do not forget visual and audio surveillance (cameras - microphones) for all development areas including entrance points (check with legal first : ). Physical security also includes secure wiring, secure IDFs and Comm Room, and secure air space. Make sure that you monitor the airspace for rogue wireless devices. Again, make sure that “no wireless devices are permitted” policy is in effect. Create a break room for developers’ personal calls outside the secure perimeter. Allow desk phones for all developers with full recording.
Layer 4: Limit Data Transfer to end point:
Even if you use a remote session architecture like Citrix or VDI, remote onshore data can still be transferred to local offshore systems; make sure that you control desktop copy/paste clip TWAIN functions, mapping local drives, redirection of local scanners, printers and other USB attached devices and print screen features. Session recording might be needed for additional security. Do not allow direct Internet or outside access. Again use another session to a secured kiosk (via Citrix, RDS) and allow internet Access via remote kiosk, make sure that all activity is monitored on kiosk systems. Disable data transfer from kiosks to development systems.
Layer 5: ITIL is still good for security:
Very basic security features such as change management, asset management, problem management service management etc are still fortifying your security posture, make sure that all changes go through a management system and they are monitored. Make sure that infrastructure support team and the application development teams are isolated from each other.
Layer 6: Monitor Network Access:
Only authorized parties should be on your ODC network after proper authentication. Make sure the 802.1x is in place for all wired ports including voice, surveillance, building management. AV, data, management etc on all access ports, no port should be left unmonitored /all unused ports must be disabled. East West network access must be restricted to “need to know” : Multimedia projectors do not need to communicate with developer systems…I strongly recommend disabling all wireless access since you cannot control physical perimeter with wireless, if you will use wireless, make sure that you acknowledge the risk of operating in without physical perimeters. (The starters are cell phone cameras)
Layer 7: No Cleartext on the wire:
If you can encrypt the data, you should. Usually encrypting from application to servers.. There are many ways of encryption but make sure that key management is in place, and use HSMs where you can. It makes sense to store all data at onshore facilities.(and store nothing at offshore)
Layer 8: Security zoning at Data Center:
Your remote desktop /Citrix/VDI sessions will be run at your onshore data centers next to your production crown jewels. Make sure that they are segmented (hard) from your offshore development environment. Make sure that you do have proper QA and rights handover from app-dev groups to prod/ops groups when your applications come to live. I do recommend physical security / DLP / IPS / Firewall type of controls to separate Development, Test, QA, Staging and Production environments. Segmentation does not end with firewalls you will need proper handover of administrative roles, vulnerability assessment and vetting in between. (Separation of duties). User authorizations for developers must only work on development systems, make sure that the zoning policies for user access rights and privileges are in place and they are monitored.
Layer 9: Obtain proper test data:
Data Masking is huge in large development project; Make sure that the development teams do not have full visibility into actual customer/secret data. This is a tough task in many cases, if you cannot achieve this, make sure that your other controls are in place to avoid data loss, and compliance based problems.
Layer 9: Divide your applications into pieces:
Remember Lord Voldemort and the horcruxes and do not put all your eggs in 1 ODC basket. This is an old known trick, if it makes sense, distribute critical pieces of applications to different / isolated ODCs so that a compartmentalized data loss at one of the development centers do not cause the complete loss of all intellectual property. This method is used by many defense contractors for years (I believe there is a term that I do not know about this) ..Even if the whole fighter jet production were outsourced, critical pieces were always coming together at trusted facilities. You may certainly use the same logic on application development.
Layer 10: Monitor and manage everything – Centrally
Collect event logs, surveillance images, change logs, anomalies, administrative access logs, user access logs, critical transaction logs, software repositories, and physical access logs; collect everything that you can have access to, and then try to deduct meaningful security information from the data. This is a difficult task, especially mapping physical access to logical systems is a tough area with no solid solution sets. Many shops with large SIEM deployments are trying to fix monitoring problem, with normalization, consolidation and correlation of diverse log input with software, it turns out there is a great need for people in order to achieve this task as well.
In the mean time try to manage systems centrally, preferably from the onshore location.
Layer 11: Centralize Administrative Access:
Developers will need to connect to many different systems, you cannot simply lock them down in a PC based development environment. They need servers, databases, utility systems, file storage , SAN etc.. all enterprise features. Make sure that you have proper segmentation and development zones set on all developer access. Also use a privilege escalation management system so that developers can access to the systems without gaining actual passwords, and all access is monitored when they do access. Usually kicking of administrative access from a session recorded jump station addresses many of the security concerns
As I have stated at the beginning, this is a quick dirty start, but as you can see this is more than “We have SAS70/ISO 27001 discussion. Writing is cheap, application of these controls are difficult and sometimes very resource intensive. So technical know-how and risk based prioritization helps.
Please let me know if you are interested in the specifics of any technical controls.
Cheers,
- yinal
