Lightweight Security Framework for Developer

Common Security Frameworks are too abstract and far away from service development. There are a plenty of security related frameworks like: ISO 27000, COBIT, BSIMM-V, BSI 100, x805, NIST SP 800-12, Basel II, Cisco SCF etc. They are all  excellent comprehensive models from security point of view.

Drawback of the security models is the huge information and missing integration in the various developing models. The development use agile, scrum, waterfall, ITIL etc. style of development and it is not obvious how it maps to the security model.  

The trend: agile and rapid development does not fit in the heavy security models. It looks like a dinosaurs of security and mouse of tiny agile development. The security mainly uses top-down approach, multiple committees, segregation of duties etc. The development currently makes shots cycles, sprints of 14 days for example, continuous development, flat hierarchies etc. It is very difficult to handle agile models with heavy security standards.

All this motivated me to develop as light as possible security models which are:

• Understood by the developers and reflect most common development cycle
• Cover as many as possible security aspects and be touch-point to security departments
• Do not require intensive study than a short lookup to get the point 

This model bases on ITIL cycle as most common, but sure can fit in ISO 9000 Plan-Do-check-Act. It is not comprehensive buts cover most of the security problems.

Design Phase: 

There 7 important security questions which needs to be discussed

• Authentication – Do you have properly implemented user authentication 
• Authorization – How to you assure only authorized user access features (data). 
• Horizontal attack - user A tries to access information on other user B 
• Vertical attacks: User A try to obtain higher administrator rights
• Integrity – How you prevent data to be manipulated. 
• Commutation to the front site
• Data stored in the database.
• Confidentiality on:
• The commutation to the front 
• Stored data
• Auditing – can you audit the data or is it needed to be audited by the legal authorities?
• Intrusion – how you detects or prevent and intrusion? Can you detect employee trying the hack a web portal for example.

The main Blocks are:

• Threat model – What are you protecting from? Thus: insider, internet user, intranet, hardware access etc. This must be very clear before designing any technical mechanisms. 
• Risk management. You may want to protect from all possible attacks, but costs will not allow this for sure.  Risk management (risk = potential loses X likelihood)  helps you at early stage to agree what are the risks to be address : you may implement some countermeasures to reduce the risks (mitigation). Alternatively, you may transfer the risk to some else (who is better paid and you hate).  Risk Acceptance means it is not worth of inversing in mitigation. With Risk Reject you agree that this cannot be handled and stop the service.
• Technical Mechanisms. This is the main part, where the technical aspect are described (similar to high and low level design)  
• Incident handling, Auditing and Monitoring need also to be well planned in the design phase.

It is very important to understand that you have two aspects

• Service. For Example an  E-Banking Service 
• Underlining infrastructure (OS, Application Server, Network) 

There are different planes, which need to be covered:

• User Plane, where you deliver the service
• Provisioning, where you automatically provision customer (probably) by the business. 
• Management and Administration – Where do the administrator manage this service. 

Transition Phase

Acceptance tests are done as quality assurance and general hand-over to operational department. From security point of view, there are some very important tasks

• Code and Configuration/Settings evaluation. Make a cross check if the code is well written and configurations hardened. They referred as a white-box  evaluation.
• Ethical hacking. You may preform penetration tests (black box or gray box)  by independent group.  This may be like simple certification.  It can be very valuable to end product customer.
• Risk Management. In all these cross checks, there will be some finding. You need to make again risk management to set what to fix and what can wait.
• Security Training –   as part of the general Service training 
• Simulation.  You should practice some precedents to see how the organization and processes are working.  The exercise are extremely important, think on fire exercises.

Operation

• Security Monitoring – Do you know who is happening on your front servers?
• Incidents handling. Handle incidents for example server hacked
• Vulnerability management -  security patches on daily bases are very important 
• KPI and Analysis – you cannot improve without quantitative measurement. The main problem is  conflict of interests – mostly the responsible colleagues for KPI are the same responsible for the operation.  So, no one gives him a bad score.
• Auditing – regular independent audit.

Big picture 

There is another small drawing which explains the relation between security strategy (long term), policy (medium terms), security technical standard etc. To realize security there must be three pillars: organization, resources (technical, docs and people) and process.  The security development cycled is part of the product development cycle.