An incident is an event that is not part of the standard operation of a service and that causes an interruption or a reduction of service. In simpler words, an incident is an unplanned interruption of service.

Metrics: how well did we react? (time to detect, time to react, time to close)

Procedures: were they adequate? were they being followed?

Root cause analysis: is the root cause understood?

Lessons learned: what corrective actions can we take?

Tip: If the incident caused financial loss, attach the current and potential security controls to the timeline. Which controls limited the loss, and which controls could be acquired in the future? Also, it’s a good idea to calculate potential losses if the existing controls would not have intervened. This will help establish the overall return of security investment (ROSI).

A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring. When to create one? Interruption of service, data loss, monitoring failure, etc.3 best practices: avoid blame, keep it constructive, collaborate and share.

For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior. A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had.

1. HTTP headers

2. Parallel requests

– HTTP 1.1 pipelining: multiple requests on a single connection; but the response must come in the same order they were requested. Browsers open like 6 concurrent connection for every host
– SPDY – true multiplexing: send as many requests as you want at once; get responses in whatever order (even in pieces). All this, over a single SPDY connection.
But this requires prioritization. SPDY leaves the decision to the server, but SPDY allows the client to mark priority requests (ex JS, CSS).

3. Server Push and Server Hint

The server can push data to the client – if the client previously established a SPDY connection.
This can be also used for sending assets to the client (ex CSS). To avoid unnecessary pushing of cached data, SPDY provides Server Hint (a suggestion to the client).

Limitations

– HTTPS needs to be used to hide SPDY
– Multiplexing happens on a per host basis (so if content comes from multiple hosts, SPDY improvements are not so visible)
– Limited browser support

HTTP 2.0: Google vs Microsoft compete for IETF specifications

HTTP 1.1 is backing up the web as we know it, but it starts to show up its age.

Google already built SPDY – a protocol that proves to be twice as fast as HTTP. Remember the OSI Model layer stack? SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection. The main features of SPDY are:
– Multiplexed streams
– Request prioritization
– HTTP header compression
– Server push
– Server hint
More details about SPDY: http://dev.chromium.org/spdy/spdy-whitepaper

Microsoft came later in the game with a kinky proposal: HTTP S&M, Speed and Mobility. The HTTP Speed+Mobility proposal starts from both the Google SPDY protocol and the work the industry has done around WebSockets. Microsoft seems to be less concerned with speed, and more concern with the mobile apps and devices, as well as backwards compliance. As far as the Web sockets are concerned, they are a HTML5 feature aimed to address the request/response architecture of the web. There is an persistent connection between the client and the server and both parties can start sending data at any time.

Review your privacy and cookies policy

Speaking about cookies, from a technical point of view, the only things you need to remember are the cookie attributes: name, value, domain, path, expires, secure, httponly. Server sets them, browser saves them and sends along with the subsequent requests. Ah, and don’t forget about session vs persistent cookies (see the ‘expires’ attributes).

Then, in the recent context of privacy and data protection, as a site owner it’s a good a idea to have a cookie audit. Not necessarily to comply with the EU’s privacy directive (the Cookie law), but because it’s good for the site owners and their users to have clearer policies and information on privacy.

Level 1 = a more prominent link to the privacy policy and improved information within the policy itselfLevel 2 = user can selectively opt in/out of groups of cookiesLevel 3 = active opt-in (the only one strictly compliant)

Next Captchas will be about recognizing objects in images

Speaking about privacy and data protection, it looks like the computers are catching up with humans. Using machine learning, a San Francisco-based company is working on a software with the goal of developing a sense of vision for the machines. By ‘sense of vision’ they mean:

– recognize letters wherever they appear,
– identify objects in photographs,
– and generally do all the stuff any kid with healthy vision can do

The first progress report says their software solves CAPTCHAs, on average 90% of the time.

Captcha’s original creator, Luis von Ahn, says: ‘An advance like this isn’t the end of CAPTCHA, although in time, CAPTCHA-breaking is likely to evolve to the point where companies will need to rely on another spambot gatekeeper. The next step is asking people to identify objects in photographs’. (http://www.popsci.com/article/technology/software-learns-crack-captchas)

UML: Generalization vs clasification

An easy one for the finish: be careful when you use a ‘is a’ relationship!
– classification – is an instance of
– generalisation – is a subtype of
Generalisation is transitive, whereas classification not.Example inspired from UML Distilled