Our business model and terms of engagement are designed as a means of ensuring value in our delivery.
The services mentioned below are in some cases not mutually exclusive from each other. Sometimes it may not be possible to deliver value if we're asked to deliver one module, while ignoring others. There are dependencies between them. At least we can say that there has to be a framework of knowledge regarding the deployment of client information assets, plus their relevance to the client's financial model.
In all cases we will attempt to leverage previous investments. For example if a client has purchased a SIEM or Identity Management system, we will attempt to derive some benefit from the investment by incorporating the system into processes. However, it should be said, we are not at all focused on products. In fact, there are very few cases where we could recommend a software or hardware product for any solution - apart from the older technologies such as firewalls and anti-virus for example.
This service is mentioned first as it's a pre-requisite for our engagement with clients. This is a service that is an absolute must in order for us to be able to deliver value.
It may help to first allay some popular misconceptions. Architecture as a service is not:
- Data flow analysis. Although data flow analysis will often be a part of the engagement, this is not the sole purpose of this service.
- Network rework, as in "router here, firewall here, segregated subnets / DMZs etc". We will always require to look at network diagrams, but secure network design analysis is not the sole purpose of this engagement.
Summarising, this is a workshop style engagement where we can get to understand the business model of the client and how it relates to IT architecture and information assets. We factor in existing security safeguards and try to alleviate these so as to help clients achieve some Return on Investment. We would need to be able to meet with primarily IT related people who can explain firewall configurations, network diagrams, and we need to understand the financial importance of information assets and applications.
This is a general name for a service that take on a variety of different forms.
Generally we wouldn't be able to target this service in a valuable way, unless we have an understanding of the client from the "Architecture" service.
The assessment would be either manual or partially automated. There is a preference toward manual methods in most, if not all areas. The decision on whether to deploy manual testing, or not, depends on the risk associated with the device or subnet. In all cases we attempt to empower clients to carry out their own testing and risk mitigation.
In most cases, for reasons not disclosed here, we would be advising clients to devote most efforts in OS configurations and custom applications.
Seven Stones has the necessary experience to allow clients to implement future-proofed processes in the following areas:
- Web application / custom apps vulnerability assessment
- Network penetration testing
- Core Technology expertise:
- Unix flavours: AIX, Solaris, Linuxes
- Pre-Windows 2008 Microsoft OS'es
- Network devices: Cisco, and firewalls (Checkpoint, Pix)
- Wireless implementations - depending on the financial risk profile, we would usually advise that clients do more than just testing for access control on Access Points. In higher risk deployments we would also advise on some safeguards in the following areas:
- Deployment network architecture (data flows) and firewall configs
- Physical, spatial analysis of the deployments
- Key management and user access control
Corporate Information Security Policies & Standards
Policies and standards form the bedrock of any information security strategy, and without them, it is going to be near impossible to future-proof improved practices.
A baseline standard must be in sync with the culture of the organisation, as well as covering off some of the higher level, management areas. ISO 27001 is a very good basis for a baseline standard.
Other standards derive from the baseline standard, but of course we cannot help in their creation unless the baseline standard has been signed off by the CEO, or top level management.
Technical standards must reflect the risk management strategy, in terms of matching OS and application security controls against the risk profile associated with the device. What is written in standards must reflect the design of real life OS and application standards. This may seem like an obvious statement to make, but in practice this point is rarely adhered to by organisations.
Incident response is another area of information security in which one part cannot be outsourced to a service provider (apart from the detection / MSP areas). If you outsource one part, the others have to be outsourced also. The parts and processes that make up an effective incident response practice are like the parts of a car, they all rely on each other in order for the machine to work.
We are well trained in this area, and we have experience of having implemented whole strategies for clients in finance and one major transport firm.
The service can be modulised as such:
- Gap analysis with existing documentation
- CIRT Philosophy
- CIRT membership, organisation, formation
- Preparedness for an incident
- Staff awareness and readiness
- System / technical preparedness