Large Software Development Shop Security Engineering Team

From Guidance Share

Jump to: navigation, search



  • Context: Large Software Development Shop for large enterprise.
  • App Type: All type of applications – “classic web”, SOA style distributed message oriented systems, reusable components.
  • App Function: Message Processing, Line of buseness, reuse. Mission critical and sensitive applications.
  • Deployment: Distributed N-Tier (web to remote app tier to database), WinForms to Web services to remoting components to back end DB. Internal and Internet facing deployments.
  • User base: thousands of end users
  • App Team: Overall 200 developments stuff built of PMs, Architects, Dev leads, Biz analiysts, testers, and developers
  • Platform/Technologies: Win2003/Win2000, SQL Server 2000/Oracle, .NET Framework 1.1, ASP.NET 1.1, Web Services, Remoting, COM+ and other MS dev technologies

Context and Problem

The software shop includes many independent development teams. All teams are required for some sort of security level in their application backed by organizational policy which is in terms of CIA [confidentiality, integrity, and availability] and hard to “translate” to actual security architecture, design and coding requirements. The policy does not go deeper to technology and development style level . There is some sort of security inspection comitee that mostly concentrated on infrasturcutre part. Most apps are not inspected for app security during the dev process resulting in actual development and datacenter policy incompatibilty. This incompatibilty resolved either by compromising infrstructure or by lame app design or poor coding styles. The personel is mostly not experienced and with high turn over. Schedules are very tight often. There are no budget for dedicated application security experts for each team but only for small team of individuals – Security Engineering Team [SET].


Using Security Engineering from p&p we’ve built ramp up training for SET team members that was based on Security Frame [input validation, authN, authZ, etc] being used througout SW development lifecycle. The training covered the following topics: * Security Engineering process and activities * Security Architecture and Design inspection * Threat Modeling * ASPNET and IIS Security Model * .Net Security Fundumentals * Security Code inspection * Security Deployment Inspection

Then we’ve built document templates for to capture the actual findings – based on Security Engineering guidelines and checklists in terms of asset-threat-vulnerability-risk-mitigation.


  • New SET members were able to get up to speed during their first project
  • Document templates enabled high ROI, e.g. – for complex projects we requiered 3 meeting and some offline work – overall from 6 to 8 hours - providing dev teams with tthreat/vulnerabilities/mitigations for architecture-design phase.
  • Dev Leads were able to assess what overall risk is app exposed to and how much investment needed – promoting this infrmation to management in understandable way.
  • Using how-to’s we offloaded developers questions from SET to “self service” WSS where they found required information

At the time of writing this internal SET team leads 8 projects for Security Engineering

Personal tools