Skip to main content


Showing posts from November, 2011

The IDABC Technical Design Checklist

This is a checklist for Technical Design from IDAC ( I nteroperable D elivery of European eGovernment Services to public Administrations , Businesses and Citizens ). This checklist can be applied within the context of an Information Technology project where a system or set of software is being designed to met business requirements. Introduction - provide an overview of the document and a description of the scope of the system and its intended usage Purpose – purpose and intended readership of document Scope – identify products to be produced; explain what the system will do; define objectives and benefits Definitions, acronyms and abbreviations – include or refer to external glossary References – list applicable and reference documents Overview – describe structure of document System overview- briefly introduce system context and design, and discuss background to project System characteristics – Summarise architecture of system. Set system context by describing high-leve

DMZ hopping gobbledygook

On the theme of leaky VLANS , I noticed Ron Trunk's IOS Security Features presentation over at Netcraftsman : I don't agree with the reasoning. The assumptions are that the switches are poorly configured and that a hacker has local access. Unlikely! Why would the switch be more likely compromised in one scenario over the other? Switches are managed with a separate management VLAN and the traffic carrying VLANs are unable to break into the management VLAN. The switches in the second scenario still need to be managed. If the reasoning is to replace managed switches with unmanaged switches then this is nuts!!! How is that more secure? (Eer, we can't see the high traffic load so it does not exist? Of course, not!!!) The Internet facing router requires ACLs to bin internal addresses and any type of management traffic. A switch compromise would require firstly a router compromise, then a firewall compromise before it would be vulnerable. If you don't trust your

Firewall's best practice holy cows

Kevin Beaver has written a best practice firewall document . He doesn't mention the holy cows in the list. The holy cows are: The firewall is security. It is all about the perimeter. Take your time to approve each firewall rule set, as this is risk mitigation. There is no need for a set of standard changes , as each change needs to be viewed separately.  Don't document . This is insecure as someone will steal it. Don't use virtual firewalls. They are unreliable and more vulnerable. Don't use VLANs. They are insecure and leak . Always use two firewalls from different vendors in a cascaded installation. Nothing will ever go wrong twice but there will be at least two salesman earning commission. Don't allow any UDP or ICMP (even for something as useful as network management.) Out of site is out of mind. Don't have geographical fail over's connected at layer 2. Layer 3 is always more secure. Don't allow dynamic routing (or for that matte

Recording the Expanded Incident Lifecycle timelines

When reporting on a major incident it is important to record the timelines. The best method to have these times is to use a screen capture tool. Alternative methods of determining these times is: If the major incident involved a server check the event log for the logon/logoff messages of RDP and use the times logged as a guideline. Make certain that the policy for auditing successful logons is enabled for all servers. The event logs can also be mined for other information. If the major incident involved network equipment use a client like Putty . Putty allows the whole session to be logged. It is a good idea to have logging permanently enabled for Putty. If you have a Cisco ACS server , it is possible to configure the network equipment to log all access and commands issued. Additional, the network equipment can be mined for syslog information either by configuring a logging buffer on the device or sending the syslogs to a daemon like Kiwi . If you worked on a system that h

Checklist for conflict resolution

Focus Focus on the issue by separating the person from the problem. No name-calling and no labeling. Be flexible, as the enterprise’s rules and policies to govern employee behavior do not cover every situation. Solutions present themselves in a culture of cooperation and compromise. Encourage responsibility by promoting the importance of raising concerns and addressing them as early as possible. Employees fearing retaliation will only "go underground" with their issues, where they fester and grow out of all proportion. Communication is both the source and solution of many conflicts. When dialogue is subverted conflict, breeds in an atmosphere of tension, misunderstanding and fear. Fairness counts and make sure that all team members are subject to the same guidelines. Negotiations Avoid defend/attack methods Obtain information by asking questions Attempt to understand all perceptions Meetings Identify areas of agreement Defer the subject to later in the mee

Checklist for Infrastructure risk assessment

Dependence on technology Level of automation All Extensive Many Some Few Sophistication Leading edge Real time Mix of real time and batch Batch mode Basic Allowable downtime Greater than an hour Greater than a day Greater than a week Greater than a month Revert to paper External interaction Outsourcing Complete outsource Most key activities outsourced Outsourcing of some key activities Some outsourcing No outsourcing Partner and contracters Untested suppliers Less well known suppliers Range of partners with some smaller suppliers Established partners Reputable partners Business unit user computing external to the system Vital part of operations Supplemental Regular Some Minimal Skills and resources Qualification and training Inexperienced and inadequately trained staff Poorly trained staff Mix of qualified and inexperienced staff Good range of skilled staff High calibre of staff Workload Insufficient resources Sho

Checklist for problem solving

The VirtualSalt problem solving checklist: Take time to examine and explore the problem thoroughly before setting out in search of a solution. Often, to understand the problem is to solve it. Breaking the problem into smaller parts will often make solving it much easier. Solve each part separately. The resources for problem solving are immense and ubiquitous. You can always do something. A problem is not a punishment; it is an opportunity to increase the happiness of the world, an opportunity to show how powerful you really are. The formulation of a problem determines the range of choices: the questions you ask determine the answers you receive. Be careful not to look for a solution until you understand the problem, and be careful not to select a solution until you have a whole range of choices. The initial statement of a problem often reflects a preconceived solution. A wide range of choices (ideas, possible solutions) allows you to choose the best from among many. A choic

Madge AccessSwitch 60 (TeleOS)

I remember being trained on these puppies at Sefton Park. The trainer was an old US Navy guy. We stayed at the Marriot near Heathrow, where he ran up a big bill on the mini bar by picking up and inspecting each drink. The mini bar worked on pressure pads.

When Bob met Alice...

Often an organization will add firewalls in an incremental fashion and end up with an administrative nightmare to manage. The firewalls are loosely arranged in a hierarchy or mesh. The answer is to connect all the firewalls to a choke as illustrated above. The latter design ensures that no matter what the diameter of the organization, only two firewalls will be traversed. The interconnect between the firewalls, the choke, becomes a great location for a IDS/IPS. A logical hierarchy can be created using rule sets and administration is simplified as connection rulesets are limited to an ingress and egress component. When Bob met Alice, there was a choke between them.

A data centre where you can flush with pride

My mate Mike, IM'd this pic to me. I have some ideas now for my upstairs loo!

Data centre checklist

Testing of data centre. Emergency shutdown test and powerup from complete light out. Consolidate servers using virtualisation. Power-supply efficiencies for servers Using networked storage can also reduce energy costs. Check for airflow blockages under the floor Leaks in the racks, which will drive up the need for airflow.Insert blanking plates, make sure those you already have are in the right place. Consider raising the temperature a few degrees. If the weather is cold outside, design air-conditioning systems that can take advantage of external air. Use variable-speed fans. Most air-conditioning fans run at 100 percent cycle and have one speed, but a dynamic fan can use temperature sensors to increase and decrease fan speeds as needed. UPSs are often over-sized and older models may not be designed to run efficiently for low utilisation rates. Store data on tape or offline wherever possible. Motion detectors to turn off lighting when nobody is working, and recycled water c

Poem by Rudyard Kipling (following the story "Elephant's Child" in "Just So Stories")

I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who. I send them over land and sea, I send them east and west; But after they have worked for me, I give them all a rest. I let them rest from nine till five, For I am busy then, As well as breakfast, lunch, and tea, For they are hungry men. But different folk have different views; I know a person small She keeps ten million serving-men, Who get no rest at all! She sends em abroad on her own affairs, From the second she opens her eyes One million Hows, Two million Wheres, And seven million Whys!

Moonies Pool

Conceptual Architecture Checklist

Conceptual Architecture Checklist from the Observations from a Tech Architect: Enterprise Implementation Issues & Solutions Blog. Original author: Craig Borysowich General The applicable analysis and design principles have been applied. The Formal Deliverables that have been produced are consistent with those defined in the knowledge base. A Current Situation Assessment has been produced, if this was not produced in the previous phase/stage. The scope of the proposed architecture has been controlled to ensure that the estimated build cost falls within the budget constraints of the customer. A review of the proposed architecture was conducted by the senior technical designate, before presentation to the customer. Requirements Satisfaction All of the requirements stated in the Requirements Definition have been traced to components of the architecture (or their feature/functions) that satisfy the requirement. All items in the proposed architecture (hardware, s

Checklist for SOX (Ernst and Young)

How are off-balance-sheet transactions and commitments tracked and reported? Are payments to the external auditing firm monitored through the transactional flags on purchase orders, check requests, or other means within the system? Are rolling forecasts deployed throughout the business (business unit, product line, functional levels)? How many tools are used in the forecasting process? The budgeting process? Do the reporting systems trace back to the general ledgers? Is cash flow from operations and generally-accepted-accounting-principles (GAAP) cash flow automatically calculated? Are key measures (drivers of financial results) delivered to operational manager's desktops daily, weekly, monthly? Are tax reporting systems integrated with the company's consolidation system? Are consolidation and reporting activities performed on spreadsheets? Do transactional reporting systems have agent-based alerts? How are manual entries identified and approved? How much time is

Checklist of IT Metrics

This is a checklist of IT metrics from APQC . IT organization Cost Effectiveness Total IT budget as % of revenue Total IT budget per employee Average time to break even for new or enhanced IT services by level of investment Number of IT customers serviced per FTE Staff Productivity Number of employees performing IT processes per <$1,000> revenue Number of IT FTEs for developing and managing customer relationships per <$1,000> revenue Number of IT FTEs for managing the business of IT per <$1,000> revenue Number of IT FTEs for managing business resiliency and risk per <$1,000> revenue Number of IT FTEs for managing enterprise information per <$1,000> revenue Number of IT FTEs for developing and maintaining IT solutions per <$1,000> revenue Number of IT FTEs for deploying IT solutions per <$1,000> revenue Number of IT FTEs for delivering and supporting IT solutions per <$1,000> revenue Number of IT FTEs for managing IT k

Microsoft's checklist for Infrastructure maturity

This checklist is constructed from this reference on Technet. Standardized Identity and Access Management Directory Services for Authentication of User Implemented Active Directory directory service for authentication of 80 percent or more of connected users. Desktop, Device and Server Management Automated Patch Distribution to Desktops and Laptops Implemented process and tools to inventory hardware and software assets. Implemented process and tools to scan client computers for software updates. Established a process to automatically identify available patches. Established standard testing for every patch. Implemented patch distribution software. Defined Standard Images for Desktops and Laptops Used tools to capture a standard image. Defined a strategy for standard images. Defined a standard set of disk images (OS and applications) for all hardware types. Established deployment tools for network-based or offline image installation. Centralized Management

The Infrastructure Prioritization Process

Each Infrastructure team leader fills in a prioritization form and brings it along to the Infrastructure prioritization meeting that is scheduled weekly. The team leader evaluates incidents, problems and work requests by importance in his area and rates them in each category in a priority of 1 to 5. Of these 15 items, 10 are selected and rated in priority 1 to 10. These 10 items are discussed at the meeting where an overall single priority list is created which is also rated 1 to 10. This last priority list is escalated to the Service Level Manager, who distributes it in an appropriate fashion. The prioritization form is attached as a tab in the uberfingers dashboard that is located here . Incident: An event which is not part of the standard operation of a service and which causes or may cause disruption to or a reduction in the quality of services and IT customer productivity. An Incident might give rise to the identification and investigation of a Problem, but never becomes