ATLAS DII(F) Network

#1
I've just received some correspondence about this network, from someone pretending to be technical. I need to de-bullshit it and de-buzzword it.

Is their an abbreviated version of JSP440 covering do's and don'ts on printers?

What on earth is 'Reach-In' printing?

thanks
 
#2
Polar,

I expect reach in printing refers, in atlas speak, to having to remotely connect to a network printer. Its similar to atlas using the term PAN data node when talking about a router. When dealing with Atlas, procastination is truely the thief of time.

You probably wont find a security regulation outside the 440 refering to printers other than a locally produced guide. The idea is that you apply the 440 rules to your situation - i.e. registering of printed output, physical security of the printer yada yada yada. I think printers are covered in brief, however you have to apply 440 rules as applicable.
 
#4
Rules and regs should all be in their Sys Syops for whatever part of the network you want to connect the printer for. Such a doc should not be heavy on the BS or should have a mahasive glossary. Of course if they are, or you're the poor * that has to write them then I wish you the best of luck.
 
#6
When is the roll out due for DII(F)? And is it going to replace the current shambles one for one, or provide an uplift in access?

We've probably got out 1 between 7 where I am, and of course these are concentrated in the useful areas - QMs, MT, RAO - HQ Sqn in general actually. When will the field Sqns (and especially the Troops) get access?

Hopefully the CO won't mind people using his terminal for JPA. I think that we were considering timesharing DII terminals it was getting that bad - I always pop down to the QMs for instant access.

CH
 
#7
Ah yes, but it should still have the rules in there somewhere. If not it'll have the name of someone who'll tell you what you can do.. heh.
 
#8
^Helps if your looking in theright place though. I thought the report had come from a big US firm begining with the letter E, it didn't.
 
#9
TA_sig said:
Rules and regs should all be in their Sys Syops for whatever part of the network you want to connect the printer for. Such a doc should not be heavy on the BS or should have a mahasive glossary. Of course if they are, or you're the poor * that has to write them then I wish you the best of luck.
Would you believe it if I said that, at the Departmental policy level, it is intended that SyOps should be no longer than 1 or 2 sides A4....

Seems that, from some of the ones I've seen, there's been a bit of disconnect between intent and reality (what a surprise!).
 

mysteron

LE
Book Reviewer
#10
polar said:
^Helps if your looking in theright place though. I thought the report had come from a big US firm begining with the letter E, it didn't.
I left the Army recently and now work for that particular company. the issue actually lies with DII(F) IPT and their interpretation. The consortium have the contract and are ready to deliver, it is the IPT that is constantly changing the goalposts.
 
#11
SigDev_Duck said:
Would you believe it if I said that, at the Departmental policy level, it is intended that SyOps should be no longer than 1 or 2 sides A4....

Seems that, from some of the ones I've seen, there's been a bit of disconnect between intent and reality (what a surprise!).
I think I'm missing something, even the smallest of systems have a fair bit that needs addressing. I'd just stick with throwing in a 1 page summary appendix. Then again I know next to jack but still write the blasted things. Keep it simple, explain the reasons to the users - suggest ways to mitigate impact on their work, they should be able to follow. Memory sticks and e-mail are the killers... Yet pretty useful.

Mysteron - you been sucked into Atlas or just an observer?
 
#12
TA_sig said:
SigDev_Duck said:
Would you believe it if I said that, at the Departmental policy level, it is intended that SyOps should be no longer than 1 or 2 sides A4....

Seems that, from some of the ones I've seen, there's been a bit of disconnect between intent and reality (what a surprise!).
Keep it simple, explain the reasons to the users - suggest ways to mitigate impact on their work, they should be able to follow.
If they read it........
 
#13
As long as we have a signature (and you mod the logon script to ensure they have to acknowledge it then when they end up publishing 'Uber Top Secret No One's Eyes only or We'll All Die' on Facebook then at least you can say they knew and understood the rules.
 
#14
^Thats partly an old school response, their is a large group that doesn't understand network security - its beyond their intellect. What you will be tempted to do in your SyOps is explain many basic COMPUSEC procedures, hopefully it will not be ignored by the customer as they don't understand it but welcomed by the JSP 440 Nazi's.

Procedures/docs - no, education to the threats yes
 
#15
Two strands of the same idea - mitigation of risk through the provision of SyOps (ie instructions to the users re how properly to use the system they have access to) and user awareness (ie explaining to users what the threats are, what the risks are, and how the individual is impacted by them).

The MoD is, in my opinion, pretty good at providing policy, not quite as good at providing guidance, and in some areas, terribly at providing awareness. How many times have you heard someone say "Don't worry about why, just do it!"? (And I'm not talking about the combat environment here... :wink: ).

There are other reasons for having SyOps, such as corporate governance, if you really want to extend the issue...
 
#16
polar said:
^Thats partly an old school response, their is a large group that doesn't understand network security - its beyond their intellect. What you will be tempted to do in your SyOps is explain many basic COMPUSEC procedures, hopefully it will not be ignored by the customer as they don't understand it but welcomed by the JSP 440 Nazi's.

Procedures/docs - no, education to the threats yes
Two sets, the full whammy for administrators to read and obey, and a 'Standard User' set of a procedures that relate to them in nice simple English. The docs are pointless if they can't be understood, and you may be partly liable for whatever resulting breaches... Although the onus is on the user to 'if in doubt, ask', it's not always practical to do so.
 
#17
TA_sig said:
The docs are pointless if they can't be understood, and you may be partly liable for whatever resulting breaches... Although the onus is on the user to 'if in doubt, ask', it's not always practical to do so.
Ha, the butt covering approach.

I don't think you can put too much onto the end user. The vast majority of the security measures have to be made by the defence contractor, if the end user manages to make a breach, I'd expect 9/10 its down to a software flaw or a configuration error by the contractor.

The main responsibility of the end user is physical security and isn't going to change from system to system.
 
#18
Oh no, but you'd be surprised how often someone decides "ah feck it I'll use this PM memory stick to move some data to the unclas one" tappity, tap, tap... "whoops I copied the wrong file, anyone got some Blanco? No? Oh well I'll just delete it and keep quiet".

In that situation they may not even report it, since they get in the shisse - but that can result in even further damage.

The contractor puts the measures in place, hopefully, but they can nearly always be circumvented by the user. It's also a trade off between availabillity and security - we could just ditch USB sticks, but then it makes data transfer between the systems much harder.
 
#20
TA_sig said:
Two sets, the full whammy for administrators to read and obey, and a 'Standard User' set of a procedures that relate to them in nice simple English.
The relevant section of guidance states that this is what should be done, i.e. that "Different roles will often need different SyOPs" and "examples of groups that may need their own SyOPs could include installation teams, network managers and users."

The really scary (i.e. realistic?) bit is "SyOPs are most effective when expressed simply and clearly in the form of a checklist." (A checklist, consisting of 10 items, does exist...).
 

Similar threads

Latest Threads

Top