Jan 23, 2013

Inside Apple: Book Review

Author: Adam Lashinsky

Lately I have become enthusiast of reading books about corporations, well, actually, about those organizations which, because one reason or another, are attractive for me. I have read about six or seven Google related books, (a hated or loved company, so you can find different interesting books about them), a couple of Microsoft related books, (an always controversial company, so very good readings also), and this one I am reviewing is not the first book about Apple I read.

Really, some of the books I read, (you can find here a review of one of them) are more focused in Steve Jobs, his personality, his different stages during his career in Apple or even the other adventures he lived creating companies like NeXT or managing and investing in Pixar. I have started to read also the famous Isaacson's biography of Jobs. I will make a review when I finish its reading.

Focusing in the book we are reviewing, the fact is that I liked specially the post-Jobs era analysis. Everybody is asking themselves about the future of Apple after the loss of their great leader, and in this book, in some of the chapters you can find some hints, well-argued from my point of view, about what can be the future of the company, in the short term, in the era of Tim Cook.

Regarding Cook and other executives who nowadays still work in Apple, I enjoyed also reading about their career path within the organization, until they achieve their current roles, the politics details (sometimes avoidable) and the different points of view about the same Apple marvelous products.

It is interesting to note how the corporate culture in Apple undergoes a deep transformation with the Job's return in the middle 90's, and it is a mystery if it will remain intact in his absence. Somebody will be surprised by certain aspects of this culture I am talking about.

Definitely, I believe that the book provides a clear and quick vision about how Apple operates, from the product idea and design stages, going through the creation or manufacturing, rolling out, sales and the subsequent post-sales service.

My rating: 4/5

Jan 22, 2013

Agile and Secure (and II)

As we talked in the previous post, we are going to analyze how to use the Agile software development methodology and produce secure software. Security needs to be included in design and coding work from the beginning. To achieve this goal the organization can take into account different ingredients. 

The development team needs software security training early on so that they understand secure design problems and risks going in, and so that they can take care of them by making the right design and platform decisions. It could be delivered formal training for developers and WA teams, either online or in person and addressing common problem areas like most common security problems in your code.  

Secure Architecture: All begins with a Secure Architecture. Depending of the different project needs you could use different approaches in inter-tier communications, authentication methods, data protection, etc. If your architecture is insecure at least you should identify stories to make it more secure and prioritize those alongside other requirements.

Verification. Static Testing & QA automation: Many Agile teams rely on automated unit testing and acceptance testing to prove that the code works. But incremental, in-phase functional testing isn't enough in itself to build secure and reliable software.

At some point you should pen test the running system. With iterative, incremental development, the system is a constantly moving target, changing every week or two. You can't pen test the system at the end of each time box — there isn't enough time. But you don't have to. Schedule a baseline pen test when there is enough key functionality in place to be worth testing, but early enough that you can learn from it and before you have built too much software that may need to be changed. And any time after you have made a big change to the architecture or the attack surface, based on risk.

Verification. Penetration testing: It is convenient to use more than one technique to verify secure software. Besides static analysis you can use penetration testing (in-house or by a third party) to double check your software.

Pen tests and other security reviews don't fit nicely into time boxes, but they don't have to — they can be run as parallel engagements especially if you are bringing in someone from outside to do the work. The team members who are needed to help out will need some time buffered from their sprint commitments, in the same way that some teams need to buffer time for support work.

Any problems found in security reviews and pen testing need to be added to the team's backlog and dealt with like any other bug. If it's a serious enough problem, it should be reviewed by the team as part of their retrospectives — not just how to fix the problem, but what it means to how they develop software, what changes they need to make to how they design, code and test software to prevent problems like this from happening again.

Fuzzing complements the methods we saw by introducing dynamic testing that finds the unknown vulnerabilities. You can find more details about fuzzing and agile development in the Codenomicon’s paper: ‘Fuzzing As a Part of Agile Software Development Project’.

The different testing approaches, (static code analysis, dynamic scans, pen tests and even the fuzzing), should be included into a continuous integration (CI)* process that periodically runs these suits of automated tests against your software. With the automated tests you could improve the quality of your applications in terms of security. There are opinions regarding the quantification of this improvement, even thoughts talking about the 80/20 rule. Personally I found difficult to give an exact percentage of improvement but what I am sure is that you will focus your efforts just in the critical ones.

[*]Probably we will talk about security and CI in future posts.

There's no reason that Agile development has to be equal as Security Fail. The technical work, the commitment to quality and detail that is required to build secure software is the same, regardless of what development approach a team follows.

Agile and Secure (I)

The objective of this post is not to discuss deeply about the Agile software development methodology, but it is worth to review some key concepts. You can read the ‘Manifesto for Agile software development’ or even the 12 principles in which derives, but basically when we talk about Agile development, we are considering an unique goal: to create a working, functional software product. With that in mind, they work very closely with project stakeholders throughout the development lifecycle, knowing it is the stakeholders who possess the knowledge the system must embody. Agile teams work very hard to deliver working software iteratively and incrementally, and they adopt techniques representative of that ideal.

There are a variety of Agile processes available to choose from, and each abide by the spirit of the manifesto and its 12 supporting principles. You can use eXtreme Programming (XP), Scrum, or other project management and development methods associated with the “Agile Development Movement”.

The strength of Agile is that it can save organizations significant amounts of development time and money, while still allowing them to deliver high-quality software.

The challenge here is to integrate security testing to the fast release cycles of Agile projects without risking test coverage, delaying release schedules or reducing features.

There is the perception today that these Agile methods do not embrace secure code and coding practices, and to some extent, historically, security has not been given the attention it needs when developing software with Agile methods. With Agile’s fast pace, it’s easy to see how many organizations would simply consider testing for application security defects to be too costly in terms of both time and resources.

If fact, nowadays is difficult to find an organization using the Agile methodology and focused in information security. You will find a good reading in this article: ‘Agile Software Development: The Straight and Narrow Path to Secure Software?

This is the abstract of the article:

 “In this article, the authors contrast the results of a series of interviews with Agile software development organizations with a case study of a distributed agile development effort, focusing on how information security is taken care of in an Agile context. The interviews indicate that small and medium-sized Agile software development organizations do not use any particular methodology to achieve security goals, even when their software is web-facing and potential targets of attack. This case study confirms that even in cases where security is an articulated requirement, and where security design is fed as input to the implementation team, there is no guarantee that the end result meets the security objectives.

The only way the perception and reality can change is by actively taking steps to integrate security requirements into Agile development methods.

In reality, since Agile methods focus on rapidly creating features that satisfy the customers’ needs, and security is a customer need, it is important that it not be overlooked. It’s obvious that application security cannot be ignored, even with the adoption of Agile development practices. It is an imperative to include security testing as part of your development.

In the following post we analyze some considerations to integrate both: agility and security.

Jan 21, 2013

Security testing and QA

Generally, those companies who are conscious about their applications’ security have introduced several practices to design, develop and roll out their software. Within these practices we could found the now well-known dynamic security tests, code analysis to find vulnerabilities (both automated and manuals) and penetration tests.

Even, the most mature ones in this sense begin to integrate security into their SDLC (Software Development Life Cycle), taking into account several security requirements in different phases of the cycle, although there are not so much in which the integration is total. The current level of integration in most cases does not include the security in the QA processes of the company.

I wonder why they are keeping out security of the rest of QA processes. Is insecure software, perhaps high-quality software? Of course it isn't, and the user’s perception of insecure software is that the product is poor quality product.

Historically, QA responsibles didn’t focus too much into applications security, being focused mainly into functional requirements, scalability and performance. Most of the time, security tests are holded over until the product is rolled out, instead integrate them into the SDLC. Even in some cases people think that security must be managed after production deployment.

The Security integration into QA processes, in my opinion, is justified considering the SDLC cost-justification curve that it shows the bug fix cost in each of the SDLC phases.

It’s obvious that it becomes more profitable to find any kind of bug in the earlier phases of the cycle, than at the end, when the software it has been deployed in the production environment; and this includes, of course the security vulnerabilities kind of ‘bugs’.

Besides that, the fact of implementing Security requirements into the earlier phases is a key point to reduce the number of vulnerabilities that will appear later. As an example you can think in the architectural design of a product, taking into account the security requirements from the beginning.

Integrating Security tests in QA processes could be a hard task. In fact, a common excuse of the QA teams when they must assume these responsibilities is that the task requires high technical knowledge and a very specific security background.

Any testing would be hard unless there is a pre-defined process and methodologies are available and practiced. In order to be successful it’s critical to first understand the existing processes, tools and methodologies the QA teams use today and then adapt security testing protocols, tools and methods to fit within those existing processes and be minimally invasive or disruptive.

Security testing executed by a specific team of Security experts will remain, but everything that you can integrate in QA processes is time earned in the whole cycle.

One of the approaches, then, to integrate both functions could be to split security testing into separate tasks:
-Things we can define/test – (automated and executed by QA teams).
-Things we need experts for.

Security is everyone’s responsibility as it has severe impact on the business if not taken seriously. So the responsibility must be shared by all the teams involved in the software creation.

Some interesting references regarding this topic:

Jun 19, 2012

Leader or follower?

What was you last amazing research in Information Security? Have you ever published a brilliant paper regarding a new technology or an undiscovered vulnerability? How many patents had been -at least- co-authored by you in this field? (yes, the last question is just for US -the weird patent addicts-)

I was wondering if there are people without any positive answer and still think that are 'Thought Leaders in InfoSec'. But, wait a minute! WTF is a "Thought Leader"?

Recently I read this post "Infosec Thought Followers" and it made me think (just a little) about the status of the industry and its "Leaders". Can you be considered as a leader just because you've good communication skills and you're good doing presentations? Yes, there are people that just get on a podium and give a talk, usually about some amazing technology researched and discovered by other.

I'm not saying that it is an easy task, however in that case I think we're not talking about real leaders.

Leadership is a complex concept but, generally speaking, there is an influence relationship among leaders and followers. Are you able to create some influence relationship just talking about something that it hasn't neither a few of originality?

If you're just a really well informed follower acting as a Leader, Can you predict the direction of the industry? Build credibility? Can you be able to anticipate a new threat? Honestly, I don't think so. You, obviously, could be a great and very valuable professional; a really trusted advisor in security for many different businesses, but please, be realistic: this is not leadership.

There are some quick tips that you must have keep in mind if you want to be a thought leader:

1-Thought leadership requires thinking. (Oh! sh1t!)
2-Be different and interesting. (No, it has nothing to do with your wool hat)
3-Don't be self-serving (Are you kidding me??)
4-Tell a story.
5-Build on your brand.

Have you thought in somebody who is doing at least four points of the list?. I know people in the security community who are doing well the last two points, and people who are really experts in not doing the third one. I wish to know more people doing well the first one...

I want to end this brief reflexion quoting the last paragraph of the post I mentioned before:

"Really, we’re all thought “followers” who absorb from one another. That’s what the community is good for. And we need all of it we can get."

Jun 15, 2012

Summer Reading List

As every single year, summer is coming and with it the same doubts about what to read or what to conserve for the cold winter.

The problem, as always, is the time available for this enormous pleasure (and intellectual need), so I've decided to organize myself following several recommendations

In summary I agree with the author of the tips that it's all about focus and it's easier to focus if you're really interested in the topic you're reading. I'm gonna start with a plan. Usually plans are made to accomplish them. Unfortunately, because of multiple reasons not always you can get them accomplished. So, please, don't judge me if I can't afford the complete plan, just think it's a way to organize my wish list of readings :) Let's plan:

June 2012

Currently I'm reading the book "Detecting Malice" by the well known Robert "RSnake" Hansen - if you're curious about Information Security you must have read some post of his blog and probably played with his famous XSS Cheat Sheet. I don't to reveal you so much content of the book, first of all because I'm still reading it, (I've read very fast the first half of it) and secondly, because I want to give you more details in a subsequent post.

There are the other books I wanna read during this month:
  • "The Tangled Web: A Guide to Securing Modern Web Applications", by Michal Zalewski.
  • Ok, it's enough technical reading ... let's change the topic: "Zero day", by Mark Russinovich ... Oh, wait! - (in fact, I've started reading this book past February, but I left it - How I hate that!  - specially because I liked it meanwhile I read it, however, as I said previously ... some circumstances... I must finish it!)
July 2012

More technical readings for this month....
  • "Hacking: The Art of Exploitation", 2nd Ed by Jon Erickson
  • "Malware Analyst's Cookbook", is written by Michael Ligh, Steven Adair, Blake Harstein, and Matt Richard. This book it has almost 2 years now but I believe could be a good reference book. (by the way, here you have a list of some Malware analysis books).
August 2012

Here I hope to have additional time for reading ...
  • "Ghost in the Wires" by Kevin Mitnick and William L. Simon.
  • "A Bug's Hunter Diary" by Tobias Klain. I really don't have very good references about this book, however I like the topic and I would be wrong in my preconception.
It isn't a very ambitious list, so maybe I can deal with all this reading.

Enjoy your summer reading too.

Sep 3, 2010

Moore's Law and Human condition.

As probably you know, Moore's law basically says that computer power doubles every 18 months with respect to a given point. Unfortunately, this law is not applicable to human brain capacity.

The most valuable scientists and engineers are working hard creating and improving lot of new technologies, but final users are not capable to follow this speedy evolution.

As I read recently, Sergey Brin said something about this referring to Moore's Law in an ironic mode. He was explaining how the Google search engine works and how it can index the entire Web, so he said "On our side, we have Moore's Law", the real problem, Brin said, is that people can't process thousands of search results "Humans, unfortunately, are not subject to Moore's Law right now. They've been evolving a little bit slower. That's a big problem. Really we need to address that." (The audience laughed).

I believe that Sergey  was very optimistic. I think that in some cases our evolution is not only slower but it's truly a regression. Or let me think that at least there are two forks. People that are evolving and whom not.

It's a curious contradiction. We can create Full HD 3D television and the content providers shows us things like 'Big Brother' or '16 and Pregnat'. Not to mention about the Internet. This is an amazing communication platform but, seriously, Do you think that we are squeezing all its benefits? ...