• This is a stand-to for an incoming competition, one of our most expensive yet.
    Later this week we're going to be offering the opportunity to Win £270 Rab Neutrino Pro military down jacket
    Visit the thread at that link above and Watch it to be notified as soon as the competition goes live

ICT Acquisition - a tale of woe

#21
Have a look at some of the Information Assurance products that L3-TRL are making in Tewkesbury - specifically Mini-CATAPAN LITE.

Cheers

Berlin
Very nice stuff it is too. All the same, no system is idiot proof if you get a smart enough idiot <Cliche generator off>. Almost all breaches nowadays are due to human factors such as social engineering rather than poor underlying system security. I have seen some outstanding demonstrations of this, including one early this year in an exclusively IT/CIS community as part of pen testing. Stupid, stupid, stupid, but I haven't seen one fail yet.

So... we are generally agreed that the lower ILs (Which is the new Cabinet Office speak for Impact Levels or security classifications/domains to us normal people) are not the real issue. I think that's what I said early before A2 Matelot violently agreed with me. The higher levels will always be problematic as it is almost always impossible to demonstrate that a vendor's equipment is completely secure (and functional for that matter) so everyone likes to make their own bespoke, customised and Heath-Robinson solution.

Some owners are so sensitive to this risk that they will not even recognise that there is crypto strong enough to allow their classified traffic to be carried on the same bearer as that of a lower classification.

However, it has been done before and is being done now. No system is completely secure, everything is susceptible to intercept, denial, disruption, misuse or insider threat. At some point you have to accept the risk otherwise you are paralysed and get nothing done.
 
#22
So how to change the process of determining the User info reqmts?
When I was working for a defence contractor the trick was to ask (RAMC/RAF-RN Medics) SNCO's on the project, they were a lot closer to the user requirement. Officers were difficult to deal with because they felt they had to manage requirements, that tends to make their requirements paramount and they also had to be seen to be knowledgeable technically. It was always difficult to see what needed to be done.

I don't think it's anything new, you can find older versions of the problems here: http://www.amazon.co.uk/dp/1177970864/?tag=armrumser-21
Quite a good geek history book :)
 
#23
From one viewpoint, as someone who spends a lot of time on the hardware level. MoD is pretty f**king stupid in some aspects. Witness the amazing contract that gave us the Bowman laptop and the Bowman network. DGIFH. How the f**K did no one notice that someone already makes hardened laptops used in pretty demanding industries and got conned into buying that abortive piece of out of date crap ? Why the unique, made just for us, USB and Ethernet cable connector at great expense and complete and utter uselessness ? Who the f**k signed off on a contract that locked us into using a limited number of printers that went out of support by the makers before we finished rolling Bowman out ?
 
#25
From one viewpoint, as someone who spends a lot of time on the hardware level. MoD is pretty f**king stupid in some aspects. Witness the amazing contract that gave us the Bowman laptop and the Bowman network. DGIFH. How the f**K did no one notice that someone already makes hardened laptops used in pretty demanding industries and got conned into buying that abortive piece of out of date crap ? Why the unique, made just for us, USB and Ethernet cable connector at great expense and complete and utter uselessness ? Who the f**k signed off on a contract that locked us into using a limited number of printers that went out of support by the makers before we finished rolling Bowman out ?
That so of stuff will always happen. What is wrong, is that there is no real mechanism to go we messed up with the requirement, we need to fund a late change.
 
#26
OK so far then:

Improve our requirements definition using expertise irrespective of rank, using commercial speak rather than 'specialised mil jargon'. From the EOD example, I take that we shouldn't be too ambitious in future gazing. Incremental is better than the 100% solution that will be future proof. From the sy and cost angle, cater to the 80% leaving the higher classification and deployable to a 'bespoke to mil' solution.

So if this is the case, then priority in the ICT world should be to the ABC principle. Not the CBA principle we seem to be employing now 'becoz we is speshul'.

I still think more could be done with OGDs - some end apps may be different but the storage, longhaul aspects, maintenance, service wrap etc could benefit from economies of scale.

Anyone know if other militaries have had better success, or is it a fact of life that the mil will arse up their contract, and industry will take us for a ride?
Can you explain the ABC not CBA statement.
OGDs - not a chance, everyone is to busy/insular/not bothered to create an effective WG. Also, who would we send on it? There is no way that the military could send the right person, well no way that the Army would send the right individual.
 
#27
Can you explain the ABC not CBA statement.
Airways, Breathing, Circulation, not Combat Body Armour.

This is exactly the point I was making earlier. Communication is insular within the MOD. Institutionally messed up communication of requirements and methodologies.

I suspect/think he meant that the MOD currently do "Create, Buy, Adapt", rather than "Adapt (the product), Buy (if you can't adapt it, adapt your need), Create (if you NEED a bespoke solution).
 
#28
Airways, Breathing, Circulation, not Combat Body Armour.

This is exactly the point I was making earlier. Communication is insular within the MOD. Institutionally messed up communication of requirements and methodologies.

I suspect/think he meant that the MOD currently do "Create, Buy, Adapt", rather than "Adapt (the product), Buy (if you can't adapt it, adapt your need), Create (if you NEED a bespoke solution).
TBH. The bulk of what MoD needs exists out there already. It's just "Create" appears to be the default response.

Think Reports & Returns. They're basically just tables into which you input a limited number of choices which are mostly numbers. You could write a R&R wizard that just asks you to input data and then send. Not tricky. You could bang something together in any one of a number of choices, from Excel to SQL and make them editable at a suitable level to ask for non standard info and that's it. Nowt tricky or clever about that. So why create something when you can write something on a Wednesday morning that does the job ?
 
#29
TBH. The bulk of what MoD needs exists out there already. It's just "Create" appears to be the default response.

Think Reports & Returns. They're basically just tables into which you input a limited number of choices which are mostly numbers. You could write a R&R wizard that just asks you to input data and then send. Not tricky. You could bang something together in any one of a number of choices, from Excel to SQL and make them editable at a suitable level to ask for non standard info and that's it. Nowt tricky or clever about that. So why create something when you can write something on a Wednesday morning that does the job ?
Support, support, support
 
#30
TBH. The bulk of what MoD needs exists out there already. It's just "Create" appears to be the default response. Think Reports & Returns. They're basically just tables into which you input a limited number of choices which are mostly numbers. You could write a R&R wizard that just asks you to input data and then send. Not tricky. You could bang something together in any one of a number of choices, from Excel to SQL and make them editable at a suitable level to ask for non standard info and that's it. Nowt tricky or clever about that. So why create something when you can write something on a Wednesday morning that does the job ?
I don't see that as core Corps business. The Corps provides comms to HQs. The apps are what the HQ needs to run on top of the comms. If the Corps of today (and I accept I am out of date on Corps issues) is getting bogged in the weeds of the apps, I'm not sure it needs to be there. If Comd Arty needs a targeting app, then that's Arty business. It would be nice if his fire plan generated the requisite Engr support for the gun revetments and the log spt to deliver/replen the ammo. But is that Royal Signals business?
 
#31
Support, support, support
Your right to a certain extent but you could get around some of that by better staff.

You also have a extra management costs associated with government projects. I worked a link between Oracle HRMS system and a medical system for an Airline that took 2-3 days to complete, also worked on the same Oracle HRMS (JPA) to a similar medical system that took 1-3 months.
Software was roughly the same, main differences being security standards to adhere to, lack of technical knowledge/experience in some staff, number of capbadges/departments/companies involved, etc. You could say being more agile would help but how do you do that in government organisations?
 
#32
I don't see that as core Corps business. The Corps provides comms to HQs. The apps are what the HQ needs to run on top of the comms. If the Corps of today (and I accept I am out of date on Corps issues) is getting bogged in the weeds of the apps, I'm not sure it needs to be there. If Comd Arty needs a targeting app, then that's Arty business. It would be nice if his fire plan generated the requisite Engr support for the gun revetments and the log spt to deliver/replen the ammo. But is that Royal Signals business?
But someone needs to do this. I believe that the IT dept should know (be the experts) the data of the organisation it supports, individual departments are the data/information experts in their domain but the IT dept pulls this all together, inter links it, enables sharing and exploits it. No department should be a data silo.
I suppose this still fits in with each corps owning apps but they shouldn't own the data (inc databases, servers, etc). Surely this is corps business if not which other corps gets the role?
 
#33
I expect there is an argument that the Corps needs to do the app piece in order to survive.

In civvy telecom, the service providers (BT, AT&T etc) are becoming dumb pipes, and will not survive in their current form if this "net neutrality" argument is allowed to win. It's not that far of a stretch to see the same argument applied to the military.

I dunno, I've had 5 Guinesses, and whatever the outcome, it isn't my business anymore. But I do work in civvy telecom and the MOD needs to get with the program. Not the other way around.
 

A2_Matelot

LE
Book Reviewer
#34
Have a look at some of the Information Assurance products that L3-TRL are making in Tewkesbury - specifically Mini-CATAPAN LITE.

Cheers

Berlin
Cheers. Been following and using catapans since they were in development. Can't solve all of our problems but help eat a chunk of the elephant

Thankyou. Been pushing this since their products were being developed. V useful. Won't solve every problem but will help eat a chunk of the elephant
 
#35
I don't see that as core Corps business. The Corps provides comms to HQs. The apps are what the HQ needs to run on top of the comms. If the Corps of today (and I accept I am out of date on Corps issues) is getting bogged in the weeds of the apps, I'm not sure it needs to be there. If Comd Arty needs a targeting app, then that's Arty business. It would be nice if his fire plan generated the requisite Engr support for the gun revetments and the log spt to deliver/replen the ammo. But is that Royal Signals business?
Actually, and please don't see this as a personal dig, that approach kind of points out one of the key issues. The Army operates a rigid closed shop setup that the old school trades unions would be proud of. Rather than JFDI far too many decisions devolve into a trade/cap badge based slagging match leading to demarcation of responsibility that industry finds laughable. The trade tail wage the task dog.

Again, not (for once) a dig at the scaleys but since they're the obvious case here - given the way technology has changed since they formed why do we expect their job to be anything like it used to be ? How on earth can you set their job in stone given the way technology changes - shouldn't we expect to see their core business redefined every five years and expect it to be different ?
 

A2_Matelot

LE
Book Reviewer
#36
Improve our requirements definition using expertise irrespective of rank, using commercial speak rather than 'specialised mil jargon'.
Which is exactly what DCNS is doing and adopting commercial strategies to make best use of this.

So if this is the case, then priority in the ICT world should be to the ABC principle. Not the CBA principle we seem to be employing now 'becoz we is speshul'.
Exactly we are looking first at what is a standard industry offering and asking for that and only asking for additional services where there is a genuine proven need.

I still think more could be done with OGDs - some end apps may be different but the storage, longhaul aspects, maintenance, service wrap etc could benefit from economies of scale.
We do this already OGDs use DFTS services and procure from that catalogue, they use Skynet5 services. To share storage, service wraps etc I think may be a step too far at this time.

Anyone know if other militaries have had better success, or is it a fact of life that the mil will arse up their contract, and industry will take us for a ride?
The Australians under JP2047 are doing this now - they're doing it vert differently though in that they are contracting for a services integrator who will own and manage the entire supply chain and will optimise that to make savings, whereas we, the MoD are doing that ourselves as the cost and perceived risk to contract an SI was deemed to great at this time.

Oh and I should have added, solutions to some of these issues will need to be found cos, more attention is now being placed on BYOD i.e Bring Your Own Device - i.e a Dept ain't going to want to fork out for its infra (end User devices - i.e terminals) anymore, which it will then need to maintain, and refresh every so often. It would rather a User uses their own iPad, Blackberry, tablet, laptop together with cloud storage protected by PKI, and access via portals.
CTO direction is that we will seek to adopt CYOD to retain a degree of control and security. The whole UAD issue is being considered now, tablets, smartphones all being looked at which means an MDM services, which means an IDAM service..starting to take a very pragmatic enterprise approach - affordability will still be an issue.
 
#37
Ah, I see what you were suggesting now. We had that where I used to work - the secure network (where we did our real work, but everything had to be typed in by hand) and the admin network (separate machines, separate cable runs around the building). Here's the question - how do you actually use the data? If you can't do any work except at that one site, it had better be one of those old Soviet-style science cities, or Los Alamos, because anywhere else you're going to have multiple sites and teams needing to share information.

Unfortunately, if you make something incredibly hard to do, people will subvert it - human nature. They'll make excuses to themselves about how it isn't really risky, or that it's really saving them time, but somewhere there will be a PC with a working USB port... and for months or years, it will be fine, and then some d***head will plug their personal USB stick that they've never used anywhere else, ever, honest, and bye bye. Or someone will run an exposed cable between the two buildings that need to talk over the secure network. Or someone will need access to that secure data from a remote site.

The question would of course be "so - exactly how do you think the Iranians organised their centrifuge-control machines to protect against threats like Stuxnet; separate network, physical security, multiple passwords?". As for physical cables rather than microwave networks, take a look at the operational history of the USS PARCHE.

You're also making the mistake of forgetting about rubber-hose cryptography :) as ever, XKCD to the rescue...

View attachment 144295

All computers can be on the private network (except those with internet access not sure how that works for email)

The basic question is why do people need remote offsite access?! Obviously it depends what apps are being run on it



Posted from the ARRSE Mobile app (iOS or Android)
 

A2_Matelot

LE
Book Reviewer
#38
All computers can be on the private network (except those with internet access not sure how that works for email)

The basic question is why do people need remote offsite access?! Obviously it depends what apps are being run on it



Posted from the ARRSE Mobile app (iOS or Android)
I've had great fun in recent months asking why we spend the huge sums we do on the internet gateway - why we can't go back to a private network or have air gapped internet capability. I accept some people do have a legitimate need to access the internet for all manner of reasons, BUT having looked at the EGS logs for just one day it is mind boggling how much time and effort is squandered.

Personally I think we should review it, we remove (reduce) a huge cyber vector, reduce complexity, reduce cost - and we'll spot those people who really need it.
 
#40
I don't see that as core Corps business. The Corps provides comms to HQs. The apps are what the HQ needs to run on top of the comms.
Since the RS have taken in the mantle of ICT then the Corp has taken in the mantle of Support for everything ICT based and that does not mean they can ignore the software requirements. It's just simply not very bright to claim that RS just does hardware as it leads inexorably to "Problems" in the ITIL sense of the word, and "Problems" cost money.

In my line of work someone got the sack for rolling out a badly tested Change that triggered about 20 Problem records within the week.
 

Similar threads

Latest Threads

Top