ATLAS DII(F) Network

Discussion in 'Royal Signals' started by polar, Apr 25, 2007.

Welcome to the Army Rumour Service, ARRSE

The UK's largest and busiest UNofficial military website.

The heart of the site is the forum area, including:

  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.
     
  3. oops.

    Editted: Seems ATLAS has many companies, inc. one a bit to close for comfort.
     
  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.
     
  5. If it was only 'a printer' :twisted:
     
  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. 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!).
     
  10. mysteron

    mysteron LE Book Reviewer

    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. 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. 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...