Book highlights: Willpower: Rediscovering the Greatest Human Strength by Roy Baumeister and John Tierney

This book about Willpower by Roy Baumeister and John Tierney is worth reading it to prepare the next term, especially when the to-do list is long and the leisure temptations are formidable.

In a super concise nutshell, and never replacing its reading, the points I highlight for those Information Security experts following this blog already for years are the following:

- A monthly plan is much more effective than a daily plan. Days go differently as planned but months give you the time you need to achieve your goals.
- Short-term targets need to be anchored to long-term targets, otherwise they are very dangerous.
- Our will power requires energy. More specifically, it requires glucose in our brain.
- Decision taking also requires energy. If you have no energy, do not take decisions that time.
- We can train our will power. Start with baby steps, right as I recommend in my IT Security Management book.
- Being part of a community with goals similar to ours always help to grow will power. The opposite is unfortunately also true.
- When you prepare your to-do lists, fine grain your complex goals into manageable activities.
- Proposal: Work with bi-weekly or monthly plans and revise them.
- For parents: Make your children participate in the creation of the family's plans and their plans (and even yours).
- If you are tired, do not decide or get exposed to tempting situations. Maybe the most important learning point of this book.

Happy will power!

The sky is the limit

Book Review: Site Reliability Engineering. How Google runs production systems

Intro
The following points come from a book by many Googleans and related colleagues such as Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy title "Site Reliability Engineering: How Google runs productions systems".

Disclaimer
Disclaimer: As always, in every book review I have posted, these reviews are just invitations to read the book. Not a replacement!

Rationale
"Traditionally system developers ended their task once we threw their creation into production". This brought only trouble both to the final customers and to the staff in charge of providing the service.

Objective
This book is basically Google's attempt to revamp the role of system administrator and operator in production. To place it at the same level system developers were and are.

How?
No magic solution, just common smart sense i.e. giving system admins in prod the possibility to improve the system themselves, to automate and to scale. The authors confirm that their proposal is a specific DevOps way.

Automation
From manual steps to externally maintained automation, both system specific and generic, then to internal automation and finally autonomy.
Reliability
How do they define reliability: "Probability that a system performs a function with no failure under stated conditions for a period of time". An outage for the SRE, when planned, is a change to improve the system, to innovate.

Service reliability hierarchy
Bottom-up: Monitoring, incident response, post-mortem/root cause analysis, testing and release procedures, capacity planning, development and product.

"Hope is not a valid strategy"
70% of outages come from changes in a live system.

Monitoring
Monitoring software should do the interpretation and humans be notified via alerts, tickets or logging (according to the criticality). No email alerts, use a dashboard with flashy colours. Nowadays monitoring is more a collection of time series (more powerful than only SNMP) i.e. a sequence of values and timestamps. The data source for automated evaluating rules.

Black box monitoring (how is the user experience?) and white box (monitoring system internals).

This way we reduce the MTTF (mean time to failure) and the MTTR (mean time to repair).

Latency vs throughput
System engineers need to understand what is best for their system, the smart mix between latency (how long) and throughput (how many). Think about cost vs projected increase in revenue. Key point: Aim for the right Service Level Objective. Do not overachieve. Over-achievement in terms of availability prevents you from innovating and improving the system.

Avoid toil
Manual, repetitive work needs to be automated. Monitoring data not being used is a candidate for renewal. Blending together too many results is complex. In a 10 to 12 SRE team, 1 or 2 people are devoted to monitoring.


Release engineering
Includes also config management at the beginning of the product lifecycle. Frequent releases result in fewer changes in between versions. Distinguish between inherent complexity and accidental complexity and avoid the latter.
In software, less is more (and more expensive). Versioning APIs is a good idea.

Incident management teams
Multi-sites teams incur in a communication overhead. How do you know the team is in the sweet spot? When handling an incident takes 6 hours, including root cause analysis and post-mortem. Prefer the rational, focused and cognitive (procedure-based) process rather than the intuitive, fast and automated. Provide clear escalation paths and follow a blameless postmortem culture. Use an incident management web based tool.

Avoid operational overhead. If there are too many alers, give the pager back to the initial developer. Prepare for outages, drill it, test the what if...?  Team members should be on-call at least once or twice per quarter.

Separation of duties in incident management: ops (rotating roles among teams and time zones), communication and planning.


Testing
Testing is continuous. Testing reduces uncertainty and reliability decreases in each change. Include configuration tests.


Team size
It should not scale directly with service growth.


Best practices
Fail safely. Make progressive rollouts. Define your error/bug budget. Follow the monitoring principles (hierarchy), make post-mortems and include capacity planning.


Latency
Look not only at mean latency but also at distribution of latencies. Prevent server overload by means of built-in graceful degradation.


Availability
Leader election requires a reformulation of the distributed asynchronous consensus problem. It cannot be solved using heartbeats (but rather replicated state machines). A byzantine failure is e.g. an incorrect message due to a bug or a malicious activity.


Production readiness review
An early involvement is desired. SRE can only work with frameworks to scale. Data integrity is the means, data availability is the goal. 

 
Rocky landscape
Happy reliable reading!
Interested in the mindmap of it? Here you are part 1.


And part 2.


Book Review: Practical Data Science with R by Nina Zumel and Jim Porzak

This is a very very brief collection of points extracted from this book titled "Practical Data Science with R". For those starting in this field of Data Science a recommendable foundational reference.

The main parts: An introduction to Data Science, modelling methods and delivering results.

As always, an important disclaimer when talking about a book review: The reading of this very personal and non-comprehensive list of points, mostly taken verbatim from the book, by no means replaces the reading of the book it refers to; on the contrary, this post is an invite to read the entire work.

Part 1 - Intro to Data Science

I would highlight the method the authors propose to deal with data investigations:

- Define the goal - What problem are you solving?
- Collect and manage data - What info do you need?
- Build the model - Find patterns in data that leads to a solution
- Evaluate and critique the model - Does the model solve my problem?
- Present results and document - Establish that you can solve the data problem and explain how
- Deploy the model - Deploy the model to solve the problem in the real world.

Part 2 - Models

Common classification methods such as e.g. Naive Bayes classifier, Decision trees, Logistic regression, Support vector machine.
To forecast is to assign a probability (the key is how to map data into a model).

Model types: Classification, scoring, probability estimation, ranking and clustering.
For most model evaluations, it is usual to compute one or two summary scores using a few ideal models: a null model, a Bayes rate model and the best single variable model.

Evaluating scoring models:
- Always try single variable models before trying more complicated techniques.
- Single variable modelling techniques give a useful start on variable selection.
- Consider decision trees, nearest neighbour and naive Bayes models as basic data memorization techniques.

- Functional models allow to better explore how changes in inputs affect predictions.
- Linear regression is a good first technique to model quantities.
- Logistics regression is a good first technique to model probabilities.
- Models with simple forms come with very powerful summaries and diagnostics.
- Unsupervised methods find structure (e.g. discovered clusters, discovered rules) in the data, often as a prelude to predictive modelling.


Part 3 - Delivering results 

Nowadays information systems are built off large databases. Most systems are online, mistakes in terms of data interpretation are common and mostly none of these systems are concerned with cause.

Enjoy the data forest





Wannacry related interim timeline

Let me share a timeline I constructed regarding Wannacry during the last days. The interesting point I shared with some colleagues was that the patient zero (o patients) infection vector is not referenced or described as of now yet.

15th February 2017 Microsoft cancels its monthly patching for that month

9th March 2017 Wikileaks press release regarding Vault7, "the largest-ever publication of confidential documents on the agency" according to Wikileaks.
https://steemit.com/wikileaks/@ausbitbank/wikileaks-vault-7-march-9th-press-conference-transcript

14th March 2017 Microsoft publish security update MS17-010 for SMB Server
https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

14th April 2017 (according to https://www.wired.co.uk/article/nsa-hacking-tools-stolen-hackers) Equation Group (see https://en.wikipedia.org/wiki/Equation_Group) releases some exploits, EternalBlue among them. EternalBlue took advantage of the vulnerability that Microsoft patch MS17-010 fiexed.
https://github.com/misterch0c/shadowbroker/

14th April 2017 Microsoft publish their triage analysis on the exploits
https://blogs.technet.microsoft.com/msrc/2017/04/14/protecting-customers-and-evaluating-risk/


15th April 2017 Security companies analyse exploits. One example of the anaylisis of EternalBlue is the following:
https://www.trustedsec.com/blog/equation-group-dump-analysis-full-rce-win7-fully-patched-cobalt-strike/

15th April 2017 Some news sites start to wonder how come that the patch existed before the release e.g. https://arstechnica.com/security/2017/04/purported-shadow-brokers-0days-were-in-fact-killed-by-mysterious-patch/

12th May 2017 WannaCry appears in the wild
https://en.wikipedia.org/wiki/WannaCry_cyber_attack

Some sources mention that the infection vector was a phishing email
https://www.heise.de/newsticker/meldung/WannaCry-Was-wir-bisher-ueber-die-Ransomware-Attacke-wissen-3713502.html
http://www.wired.co.uk/article/wanna-decryptor-ransomware
https://www.cylance.com/en_us/blog/cylance-vs-wannacry-wanacrypt0r-2-0.html

However, no analysis yet of that mentioned phishing email, its attachment and its modus operandi in general.

Update 1: Response and proposals from Microsoft


Rocky days





Book Review: Bitcoin and other virtual currencies for the 21st Century by J. Anthony Malone

A very handy book to approach Bitcoin.


Let me try to share with you the main learning points I collected from this book. As always, here it goes my personal disclaimer: the reading of this very personal and non-comprehensive summary by no means replaces the reading of the book it refers to; on the contrary, this post is an invite to read the entire work.

The book starts first with the concept of money, how money was an innovation itself, the functions of money as a medium of exchange, a unit of account, a store of value, a deferred payment and a value measure. It also provides some insights on the history of money and how credit is older than cash and, finally, a key concept: the monopolistic role of the government in terms of currency issuance.

There are some hints in the book to consider Bitcoin a starting point to end the monopoly of central banks. It claims that the Bitcoin value scheme is inspired on the old gold standard. It is interesting to read the links that the author sees between the Austrian School of Economics and Bitcoin.

The point that Bitcoin does not have a centralised clearing house is certainly a key point in the book. It also mentions that the blockchain public ledger is the heart of the Bitcoin technology. It also mentions that Bitcoin is inflation-free (there is a fixed number of Bitcoins that can eventually be minted). The supply of Bitcoins does not depend on the monetary policy of a central authority. It also remembers the Keynesian line of thought on deflation and how it encourages individuals and businesses to save money.

To use Bitcoins, you just need a Bitcoin wallet and a Bitcoin address. Technically, Bitcoin has currently a transaction limit of 7 per second.

There is a section of the book on legal aspects of Bitcoin. Apparently virtual currencies do not have legal tender status in any jurisdiction. Bitcoin has the properties of a payment system, a currency and a commodity. There is still a bit of regulatory ambiguity in terms of Bitcoin. There are some appendixes in the book related to a very useful glossary of terms, a legal guidance issued by FinCEN in the US, also from US GAO (Accountability Office), from the Inland Revenue Service, some input from revelant regulators and legal documentation on different Bitcoin-related cases.

Happy growing!