Some Security Standards

I recently had to review some of the security standards in order to get consistency in the framework I have been defining.
For this reason I had to get some order and to grasp as much as possible from each standard “on the market”.
As a result from this work I was able to made a simple list to be used as reference in case you need to go trough the definition of security framework.
The simple explanation I’m giving is just for reference and doesn’t aim to give any insight. I will eventually update the article with more references as I will use them. Possibly for each of the standard a new article will follow.

The first and most important standard I have been following is the family of ISO 27000 (Information Security Management).The ones I used most are:

  • ISO 27001:2013 which gives in detail the requirements for implementing an Information Security Management System. This standard is one of the best to follow in order to assess the security compliance of your organization.
  • ISO 27002:2013 which highlights the best practices to set up a system of security controls
  • ISO 27005:2011 which gives the basis to set up a serious IT Risk Framework in your organization

To get deep understanding of the ISO27K the NIST (National Institute of Standards and Technology) standards are the most valuable ones. Just to note that NIST is an american agency that basically defines a series of strong standard in the system security area.

Together with NIST I strongly suggest to take a look at the The Standard of Good Practice for Information Security that give a full coverage on standard and control practices that can be fully and straightforward applied to any environment.

I got good insights from the the Payment Card Industry (PCI) Data Security Standard (DSS) that was developed by some of the major credit card companies and consists in a series of core requirements to be developed in order to achieve data security in credit cards payments

Most of the times, in order to get the big picture, I had to refer to the famous Control Objective for Information and related Technology (COBIT) or to the ITIL (Information Technology Infrastructure Library) frameworks. COBIT is basically a control framework that enables the management and right governance of an ICT system, while ITIL  is not directly linked to security but is again a series of good practices in managing and operating IT systems. As a matter of fact most of the practices have a direct impact on the security of the systems (e.g patch management and incident management).

The ones up are in my opinion the basics, while additional ideas can be obtained from

  • HIPAA (Health Insurance Portability and Accountability Act) that is a standard which aims directly to protect the confidentiality and security of healthcare information
  • The Federal Information Security Management Act (FISMA) that is an american legislation that define a framework to protect government information, operations and assets against natural or man-made threats.
  • FIPS (Federal Information Processing Standards) which represents a series of publications of the NIST that represents guidelines and standards and in general minimal security requirements that US federal agencies must follow.
  • The ISO/EIC 15408 well known also as common criteria helps to evaluate, validate and certify the security assurance of a technology product against a certain number of factors. Hardware and software are generally validated against this standard

where possible I put some links in my link page.

Best Links

Project Constraints

A constraint is anything that restricts the project manager’s options. Constraints are requirements, confines, or, if you’re a glass-is-half-empty kind of person, prison walls.

Constraints can include:

  • Schedule. You and the project team must create the software deliverable by such-and-such date — or else. Schedule constraints can also be crunched by the availability of project resources, vendors’ ability to deliver, and even access to testing facilities, server rooms, and networks.
  • Budget. Of course, you’ve got a budget, but is it enough? In software project management, the bulk of your budget is tied to labor. The longer your programmers take to create accurate code, the more expensive your project deliverable becomes. You must find a balance between the cost of work and the required quality. Additionally your budget consists of not human resources, as material, space rent, machine rent … usually however this part is know with a better detail at the beginning of a project.
  • Resources. You probably have your favorite workers that you’d like to work with on every project because simply they guarantee the result. But they can’t do everything, they’re in high-demand, and chances are, because of their skill sets, they’ll cost your project more. And even if you don’t play favorites, which I bet you do, you may still face resource challenges. Most organizations don’t dedicate their people to just one project at a time — so which project has priority for the resources you need? You’ll have to bargain, beg, and plead (sometimes) to get the resources you need and want.
  • Technology. In every project this is a strong boundary. When it comes to software project management, you have to deal with surprises, like programming in COBOL, Visual Basic, PHP on a new platform, and more. And sometimes the technology you have to interface with is so old you’ll be consulting with Leonardo da Vinci just to be backward compatible. On the other side, sometimes technology is so advanced that probably we would need doctor Spock to deal with it. All this to give the message that technology can be a huge constraint.
  • Competence. No one likes to admit to not knowing something. But if your project team doesn’t know how to solve problems, how to perform day-to-day activities, or even the functional characteristics of the product they are developing, then you’re in big trouble. You need to have an approach to skill assessment. You need to create an environment where workers are encouraged to ask for help when they need it. It’s better to train, offer materials, or hire experts to help the project than to let your team wallow in denial and produce a crappy product.
  • Management. this is the most dangerous as it sums up all the others. Have you ever said: “We don’t have enough time!”, “We don’t have enough cash!”?

Management is often setting unrealistic expectations, even if we should admit that sometimes we have to determine who’s really to blame. Usually the project managers are correct. Usually. But sometimes the project managers are so out of tune of the project management processes that they don’t know how to plan or attack the project objectives.

Other times, management has no concept of what the characteristics of the project (e.g. software development) are. Management may throw a schedule and budget together and dump them on the project manager’s desk. In these instances the project manager must communicate the problem. If the project manager does nothing other than rant in private, things won’t change and the project will likely fail.

The key here is to document the problem as a risk, share the risk assessment with management, and then document the results. If you’re faced with unrealistic expectations from management, your job is not to fail and then tell the managers, “I told you so.” (That will not earn you a promotion) It’s to say, “Here’s a problem: unrealistic expectations. How will we fix it?”

Theory of constraints Basic

Here are the basic principles of TOC that find there application in the critical chain management:

  • Eliminate Safeties from Each Task
  • Management Must Not Insist on Each Task Starting & Finishing “On Time”
  • Stagger Tasks in the Schedule Using Finish to Start Constraints
  • Start Right Jobs at Right Time Using Prioritized Task List
  • Focus on Meeting Milestone Dates, Not Task Dates
  • Single Integrated Schedule
  • Update Official Schedules Daily with Actual Starts, Remaining Duration, & Actual Finishes
  • Predict Milestones Based on Buffer Penetration
  • Focus on Task Throughput, NOT on Task Costs
  • Counter Parkinson’s Law
  • Conserve Available Float/Slack on Each Task, Reduce Time Available
  • Counter Student Syndrome
  • Start Each Task As Early As Possible
  • Claim Early Finishes Immediately
  • When Problems Occur, Solve the Problem vice Starting New Task
  • Decrease Frequency & Duration of Meetings
  • Resolve Conflicts Immediately at the Jobsite
  • Eliminate Bad Multi-tasking
  • Resources Focus on One Job at a Time, Work to Completion
  • Keep WIP Low!
  • Request Only Resources Necessary to Accommodate Priority Work
  • Request Only Overtime Necessary to Recover Buffer on Priority Work
  • Move Resources When Work is Done to Next Priority Work Quickly
  • Work Right Jobs instead of Easy Jobs
  • Plan for New Work & Scope Changes vice Complaining About it



Kaspersky released two paper which are really interesting in order to understand the level of sophistication cyber criminal reached. Here are the links

I strongly suggest to read them, some parts are technical, but some other are understandable and gives serious insight on modern cyber-crime.

Creation of a shared vision in IT

This article is following the one where I highlighted some attention points to take care when changing job, but it specifies the aspect in relation to a team of IT professionals.

Here I would like to focus on the importance of a vision, an idea a final point which will drive us to what we want to reach with the team.

I would like to stress that creating your own vision is a fundamental task which usually takes a lot of time and involves both personal (what gives me the highest satisfaction in my work) and professional (where i want to be) aspects. Additionally this isn’t a static process, but it will be normal that your vision will change as your career and personal life will progress.

Our own vision will be the result of a personal work, that we will build during or after the analysis of the situation where we will be working. However this is not enough, our idea of what we will be must be shared with our team and (most difficult) it has not to be against the one of our company. For this reason after a personal work, we must follow with a confrontation phase with our bosses and our team.

A good practice is to discuss first with our executive and then keep one or two brainstorming session with our team, later we will close the sessions with a clear commitment for getting the objectives that were agreed.

Continue reading Creation of a shared vision in IT

Risk Avoidance right from the start

Once the scope and a draft of the plan are defined, we need to star the project risk analysis.
The idea of risk is strictly related to the idea of a project: a project without risks doesn’t exist. For this reason along the whole project duration, we need to apply the correct techniques of risk management.

When we do a correct risk management, in order to reduce/eliminate the risk we found, we often need to reconsider some decisions we took during the definition/planning phase.

For this reason it is clear that deleting the risks since the beginning of the project its quite important in term of added value. Indeed, in this phase the cost of one change is still very low, since the status of many document is still open and many decision are still to be taken.

This big TO-DO list should help us in the initial phases, since it gives some ideas to find and reduce the risks related to the most importat project areas (scope, planning, resources). Maybe many of you will take it as obvious things, but, at the end, it is usually on this obvious things that we find the biggest problems.

Continue reading Risk Avoidance right from the start

Some Links

In my company I recently have been working on the preparation for a penetration test to be performed by an external team. For this reason I had to refresh my knowledge. I found quite useful the following links:

Let me know if you find other useful frameworks.

Requirement Elicitation

Following a list of some of the best elicitation (collecting intelligence information) techniques:

  • introspection: what would I want/need/desire if I were a user of the proposed system?
  • brainstorming: free association and generation of ideas for the proposed system
  • Post-It notes and white board: create, modify, group, and rearrange statements of needs and desires
  • paper prototypes: construct interfaces and operational scenarios.
  • questionnaires: which of the following features do you need/desire?
  • observation: watch people performing their work tasks
  • open-ended interviews: tell me how you would use the proposed system
  • focus groups: please tell us what you would want/need/desire in the proposed system
  • operational walkthroughs: development of scenarios by interacting with users (UML)
  • demonstrations: how to you like this interface? what should be added/removed/changed?
  • protocol analysis: document the tasks users perform and the features they would need in the proposed system
  • business case analysis: what features are needed to support the operations of our business?
  • JAD (joint application development) sessions: facilitated meetings with users
  • Work with the users: it is not always possible, but this technique gives the best result

How to define a project … without killing yourself.

In this article I will present some hints to consider when starting a project, so that we will be able to avoid “unpleasant surprise” once the work will be started. We can consider some of this points in our contract or simply keep them as project risks, but surely we shouldn’t ignore them.

This sequence is naturally applied when products of project are IT applications or are IT related, but in my opinion, many of the observation are good even in case of not-IT projects.

Sponsors and Stakeholder Expectations

Along the whole project duration we need to manage the expectations of our clients. However, the most critical moment in this task happens at the beginning of the project, when we are defining the roles, the project expectation, the deliverables and the project economics

  • Identify as soon as possible the key sponsor, the target user and other stakeholders group. We need to have clearly closed the following list early in the project:
    • who pays for the project
    • who is representing the user groups
    • “internal” users – who, inside the organzation will use the product
    • “external” users – clients of the organization that interacts with the product
    • “indirect” users – these users do not interact with the product but use what the application produces
    • support groups that later will have to maintain the product
  • Understand and document the goals and expectations from the sponsors and other key stakeholders
  • Understand and document concerns from the sponsors and other key stakeholders, and ensure that the project has a plan to address them.
  • Understand the role of each stakeholder and the influence he/she has on the project’s success.

Continue reading How to define a project … without killing yourself.