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.

What does the project leader should know or the nine phases of projects

Every project manager knows about miles stones, checkpoints, deliverables and phases. There are plenty of frameworks, ITIL, COBIT, TOGAF etc.

The project leaders all are missing the emotional phases of the project. Every new project passes through psychological phases. There phases must be guided by the project lead or scrum master. The phases for my perspective are:

1. Enthusiasm
   The start phase is the strongest one. Every one believes in the ides and gives and dreams of golden future. 
   
   
   Tip: Keep the targets very realistic. Try to keep the enthusiasm as long as possible. 
   
   
2. Disillusionment
   Soon the team starts understand how complex the things could be and the real problems. The team understands that it may repeats the mistakes form previous projects, which failed.
   
   
   Tip: Try to structure and understand the problems. Try to work step-by-step, follow framework, checklist etc. Do no make long emotional meeting which may motivated more.

3. Panic
   After the disillusion comes panic: team can not handle these problems, the management should do something. It depends strictly if the leader may control the previous state of disillusion and has demonstrated control of the situation.
   
   
    Tip: Listen and passively relax your colleagues. Try to keep focus on different     tasks. Keep the team busy. Last but to least,do not take very serious the emotional worlds like “the company will collapse tomorrow if you do not immediately ….”.
   
   

3. Search for the guilty
   This is the phase of the conspiracy, gossips and rumors. Even not obviously this is very intensive process of “we and they” separation.
   
   
   Tip: try to show always to positive characteristics of colleagues. Everyone has positive and negative characteristics. Focus on unknown bad ghost, like the “investor is the bad guy”.
   Discussions “lesson learned” is not always good solution. Criticism may burn bridges between the collages. The good relation can not be reestablished even for years. Lessons learned must be made objective and mostly by experienced colleagues. I personally prefer interviews.
   
   
4. Punishment of the innocent
   The reaction of panic is seeking for the guilty. The question if this will be known person or an unknown ghost.
   
   
   Tip: Delay the punishment as long as possible. In a month it may look different.

6. Praise and honor for the nonparticipants
   Destroying a project is easy task. Sure they are many people, who “knew it from the very beginning”
   
   
   Tip: Do no participate. Soon there will be a second project and you will meet the same project again.

There is also a positive cycle:

7. Blind playing
   The team does something but can not define in which direction and can not explain what is the purpose of the tasks. Experimenting or playing is not very motivating, because there is not a clear way.
   
   
   Tip: do not lose to much time on the same tasks even not very perfectly explored. Keep on trying different options. The management wants real results and explanation “we are experimenting” can not be justified in long term.
   
   
8. I am God
   After blind experimenting, some members starts understanding how it works. These members start feeling as a God. They start working very focused. Still there are not real result.
   
   
   Tip: Unfortunately, some people can be arrogant to other members, who are still no very competent. Try the spread the know how. Sharing is extremely important.
   
   
9. Wow effect
   The project starts delivering some results. Every one starts believe and trust the team.
   
   
   Tip: Take the wave/wind and used the impulse for further projects. On the other hand, do not over estimate the next targets.

The importance of feedback in IT security and ethical hacking

Feedback is extremely important for every person, team, department, company. I do not mean feedback, like "you are doing OK, keep on this way", but real unpolished "raw" (market driven) feedback: Does the product sells, are they bugs, are customer's complains, it is generating a revenue? (The feedback need to be interpreted in the right way for sure.)
The short period feedback is core element of agile development: build, try, correct and rebuild. Without a feedback, the professionals become less efficient and the system become a bureaucracy.
How about IT security? Security solution and policies need also feedback, but oft it is not the case in may companies. There are very important points to be addressed:

• Do the companies know how may attacks they sustained and number of successful attacks?
• How many security bug were found internal and how fast are corrected?
• Does the security policies are controversially discussed and open-minded reviewed based on experience and statistics?
• Are there mechanisms to avoid blind following on meetings? Are they anchoring effects?
• Is it clear the resources and respectively money required for additional security?
• Is it clear the consequences of not following the security recommendation, like cutting bonuses? The consequence of policy exception for the manager must be also clear, they also have bonuses in the case of security bridge because of the exception.

Even all these points are answered, there is no guaranties that the statistic (feedback) reflect the security situation. Potentially, the hackers were busy elsewhere or were on holiday :-) For this reason, it is very important to make protectively security test or ethical hacking. For example: the software departments make acceptance tests (Unit-Tests) and the security department a security tests (penetration tests).
The security department needs as much feedback as every other department. Do not hide facts from the security :-) Otherwise, it becomes bureaucracy.

Innovation and issues with Corporate Identity and Project dedication

There are some contradictions between innovation and project dedication in the context of modern corporate identity. These are mostly overlooked by the leads or not optimal addressed. 
 When an employee identifies with his task than it works harder, it is happier and ready for extraordinary efforts. On higher layer, corporate identity homogenizes the international environment and helps overcoming the country/local/language problems. Corporate identity increases the productivity because there are less personal problems, like misunderstanding etc. Corporate identity helps the people to work in the same direction. 
Sentence: Corporate Identification with and Project dedication (identification) is good. Unfortunately, there are some cross site effects with innovation.
Innovation in the contexts of creativity and agile enterprise development means: 
Trying many innovative projects or services. A few of them will lead to success, but many will be canceled, since they can not deliver the needed profitable results (see previous post). Most companies follow this principle and start many innovation initiatives and pick-up the best to core business.
The employee with high identification and dedication, who worked on canceled project have risk of frustration. The have worked hard, achieved  good results, but the project is canceled. The reason for cancel is not because of the individual  performance, but due to some technological or economical reasons. The disappointment of these colleges is absolutely understandable. People loose  dedication after 2-3 of there bad experiences. “Every project is canceled independent of my performance at the end - why to rush for the next task?”   The individual loose motivation and there is serious risk that they get fired or leave because of poor performance. This is logical since they are not motivated.
If company permanently starts new initiatives and stop every 70% of them, it is very dangerous and may lead to bad moral at work. The companies need the innovation, so they need to keep on launching initiative.
How to solve the issues?

• Make it clear to the colleagues, how it works. Make it transparent. Not transparent decisions are not understood. Clear metrics and KPIs.
• Try to involve everyone in at least one successful project. Keep the people them busy.
• Try to use external staff for the first phases (high risk) and internal people only for the second phase, where the risk of failure is small.
  

Innovation and creativity in practical experiance

Innovation and creativity are mantras for the enterprises. Many classical enterprises look envying to Google and Co. and want to generate the same results. Many consultants promise to know the secret and urge to start innovation programs.
I believe  that creativity can be catalyzed or stimulated, but there are some framework conditions. I am not going to repeat the well known methods, but only give hints of critical points for the practices.

Agile development

1. General 

• Strict structures and processes kill the creativity. Leave always a little randomness.

• Missing structure and processes in company cause that the team start organizing them, which is waste of resources. The infrastructure are the tools, so they must be present.

• Teams are always happy with sustained position of of the management.

• To reduce the destructive klatch, the team needs to have enough to do. 

• To reduce the psychological pressure and the following mistakes, the team needs time for predefined creative breaks. The members gain distance on the issue, may look from at higher perspective. This is very typical for arts (painting, music etc), so the same for engineering.
  

2. Team building

 Core rule: the team must be as flat as possible; without any hierarchy like: architects, decision maker, solution engineering, project manager etc. 
Idea: Creativity is stimulated in self organizing structured. The natural properties of the members are important and not the titles. If someone is innovative let hear him. Naturally, there must be sufficient skills for the task.
Beside the team member, there are

• product owner - defines the requirements and accepts the solution. The product owner needs to start understanding difficulties of the team. This is very important that he is not only visitor, than he needs to understand deeply what the team does.
• organizer (scrum master) takes care on administrative and organizational work.

 

Classical problems

Team members still keep titles and positions: For example: I am project manager, ergo I lead and decide. Definitely not: scrum  master is not project manger and does not decide. I am architect, ergo I say how to be build.
Manager try to influence the team: I give you the budget, I am VIP so I desire how and when. There is not way to avoid this, but it decreases the creativity. There must be a balance.
Some people can not express in perfect way they are right. The best presentation is not the optimal solution always.

3. Susses at any costs

Classical manger want success at any price on every project. Success means service delivery on time. Creativity is not really predictable in this sense.
The only way to achieve success in classical understanding is to start many activities in parallel or wait sufficiently on one activity.  If you start many activities, it must be expected that only 30% will be success.
Following, I draw the deliveries in stages (sprints) relative to the target. They are self explaining.

4. Adjust the targets

The target may be adjusted at some point of development. The product owner is part of the team and he may see some potential in not originally expected objects. That is why he need daily to participate and gain experience. (not only marketing presentations)

 

5. Permanent Feedback and net Tasks

The permanent feedback and attention to the management is very important and motivation for the team. The team must be always fully loaded with interesting tasks. 

  

"Access only from trusted zone in untrusted zone". Is this a theory-induced blindness?

Ones, the theories are well studied and accepted, they are used without a doubt  everyday as a tool.  It is extremely difficult psychologically to  find flaws in them through critical questioning as Daniel Kahneman points in his book "thinking fast and slow". Security theories have the same characteristics.

There is a common security rule: "Assess only from trusted in less trusted zone. Never on inverse!". The motivation are taken from the abstraction on figure down. There is a citadel representing a trusted zone and untrusted zone (insecure) outside. 

And now in the practical scenario:

You have a Internet customer, who use a portal to update his secure data, like health information. How can you transfer the information form untrusted (Internet) in trusted zone (data centre) according this secure rule?

Security processional try to solve this dilemma with TCP polling proxy, thus changing the direction of the TCP session establishment: only from trusted to untrusted zone. The principle is the following: the Internet user deposits its request on the web server. The internal application server polls from trusted zone on regular intervals (several seconds) and takes the request form web server's depot. The response is deposit back to the web server.

Dose this polling solves the security problem? Not realy:

• The data is transported from Internet to the internal sever, no matter of the TCP session establishment. 
• If the data contains application malware, like SQL injection, then it is transported with several several seconds delay to the application server.

Probably, the mechanism prevents form some network attacks, like SYN Flood etc? Let me assume, there is network firewall between web and application server. Otherwise, how may you trust that only polling is made - control is better. Coming back to the original questions: does the polling protects form network attacks, if there is a firewall in between? Again no, because: Every modern firewall has: port restriction, statefull inspection, rate limit, request size limits, some DoS protection etc. If these firewall features are set up correctly,  I do not see what more polling can make for the network security. IP/TCP Network attacks will be blocked by well configured firewall and web server.

I can not find any reasonable argument, why changing the TCP direction establishment may improve the security in normal case (hypothetically, we may always make use of every theology even small). Even more,  the rule "Access only from trusted zone in untrusted zone" is theory-induced blindness. The application data travels always in both directions form trusted to untrused and vice versa. Even sendig a HTTP requests "GET"  may contains a potential attack in the header parameter. For the network attacks there is firewall.

My advise: if you are concerned on your application security,  hardening, code review, ethical hacking, WAF etc may be the solution you are looking for.

Why Digest (Nonce) authentication is less popular? or the long life of the week Basic authentication

Even young professionals know the difference between the basic and digest authentication, thus:  in basic authentication - the password is transmuted in clear (reverse calculable) and this is bad. On the other side digest authentication- the password is never transmitted over the transport channel than hashes of password with random nonce. These methods  are available in WS-Security , HTTP, PPP etc.  I am not going to describe it here again, see RFC 2617, RFC 1994, OASIS WS Sec username and token.


It is obvious conclusion avoid basic authentication and use digest, thus prevent sending the password in clear. So far so good, but still digest authentication is rare. Why ?


The answer is obvious but not really understood.


If you use digest authentication, then the user passwords must be stored in your database for verification, like LDAP, MySQL, Active Directory etc. Sure, the user passwords will be protected with some master key and symmetric encryption, but the user passwords are still there and reverse calculable. Every backup copy of the DB contains all user passwords. If someone stills your master key and the DB, then - bad luck :-( The administrator needs to think twice on how to handle this risk.

If you use basic authentication, then the user passwords do not need to be in the database at all. Practical, the database will contain seeded hashed of the user password, like in the Linux system. If a bad guy obtains a copy of the database, he will find only hashes and will never be capable to reverse calculate the real passwords. Sure, they are some rainbow attacks but let us leave them for a moment aside. The administrator will definitely prefer this way, less risk for him. Potentially, he will use TLS to protect the transport channel. He will hope that client verifies the TLS Server certificate as expected ;-)

At the end:


either you send the password in clear (basic auth) and don't sore it in the DB
or store the password in your database but don't send it  over transport channel client to server (digest auth).

It is your choice, but you need to understand it.

Historically, it is interesting to know that the Telcos do not trust the transport channel but their administrator. For this reasons, they use mostly CHAP on PPP (digest auth). On the other hand, the web enterprises trust the channel, but do not trust the administrator and use basic auth in order to avoid password in the database. It is a interesting that exactly core competency is doubted even this concussion is very simplified .