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: