Page 2 of 3 FirstFirst 123 LastLast
Results 14 to 26 of 32
  1. #14
    Join Date
    Apr 2007
    Location
    San Diego, CA
    Posts
    1,330
    Osiyo, fair enough. My assessment of mechanical outfits is indeed a generalization. I'm sure there are plenty of capable outfits out there, yours included. The issue of IT merging with Facilities is still an interesting one to watch unfold.

    I'll leave you with the last of the 10 immutable laws of security (from Microsoft):

    Law #10: Technology is not a panacea

    Technology can do some amazing things. Recent years have seen the development of ever-cheaper and more powerful hardware, software that harnesses the hardware to open new vistas for computer users, as well as advancements in cryptography and other sciences. It's tempting to believe that technology can deliver a risk-free world, if we just work hard enough. However, this is simply not realistic.

    Perfect security requires a level of perfection that simply doesn't exist, and in fact isn't likely to ever exist. This is true for software as well as virtually all fields of human interest. Software development is an imperfect science, and all software has bugs. Some of them can be exploited to cause security breaches. That's just a fact of life. But even if software could be made perfect, it wouldn't solve the problem entirely. Most attacks involve, to one degree or another, some manipulation of human nature—this is usually referred to as social engineering. Raise the cost and difficulty of attacking security technology, and bad guys will respond by shifting their focus away from the technology and toward the human being at the console. It's vital that you understand your role in maintaining solid security, or you could become the chink in your own systems' armor.

    The solution is to recognize two essential points. First, security consists of both technology and policy—that is, it's the combination of the technology and how it's used that ultimately determines how secure your systems are. Second, security is journey, not a destination—it isn't a problem that can be "solved" once and for all; it's a constant series of moves and countermoves between the good guys and the bad guys. The key is to ensure that you have good security awareness and exercise sound judgment.

  2. #15
    Join Date
    Apr 2007
    Location
    San Diego, CA
    Posts
    1,330
    Quote Originally Posted by AtticusFinch View Post
    Greetings to you Digo. Perhaps you could answer the question of whether the root user is accessible other than from the console?
    The console CLI that you're used to in *unix, can be accessed locally via a serial connection using your favorite terminal emulator like HyperTerminal. The only other way to access this, would be via a very insecure method - telnet. This is disabled by default. I hear beyond 3.7, ftp and telnet will both be replaced with ssh and sftp.

    The remote connection to the platform daemon is done with Workbench - and yes, this is the highest level account in he system, which is why it's so important to change the default account/password.

    As a second can you provide the RSA key documentation?
    docRSA.pdf, was included with the 3.6 documentation. Considering that SecurID was compromised around the time of this becoming available in Niagara-AX, I don't think anyone had a chance to actually implement it yet...
    http://en.wikipedia.org/wiki/SecurID

    It is an improvement this 3.6 version started this functionality. When was this version released? Apparently the article was generated before this release.
    As kc2dnw already mentioned, Tridium release 3.6 in July/2011. 3.7 features were announce at the Niagara Summit last May, but it has not yet been released.

    Beyond this, future releases will offer SSL encryption not just for the browser session, but also for both fox and platform connections.

  3. #16
    Join Date
    Apr 2012
    Posts
    94
    Quote Originally Posted by AtticusFinch View Post
    This Niagara system platform is not designed with security in mind. So, it fails.
    I'm curious how do you know it, if you clearly have a very limited (if any) experience with Niagara? I could tell because you don't know about 3.6 release and you don't have access to RSA documentation.
    Just wonder.

  4. #17
    Join Date
    Jul 2007
    Location
    Mount Airy, MD
    Posts
    7,281
    Quote Originally Posted by pault View Post
    I'm curious how do you know it, if you clearly have a very limited (if any) experience with Niagara? I could tell because you don't know about 3.6 release and you don't have access to RSA documentation.
    Just wonder.
    AtticusFinch and Sysint, are related. Make sense now?


  5. #18
    Join Date
    Oct 2003
    Location
    Minnesota
    Posts
    1,376
    Quote Originally Posted by digo View Post
    Osiyo, fair enough. My assessment of mechanical outfits is indeed a generalization. I'm sure there are plenty of capable outfits out there, yours included.
    The truth is that achieving a basic understanding, and then taking appropriate, basic steps to enhance security ... isn't rocket science, and does not require extensive IT expertise, formal IT training, etc.

    For instance, where I work we have controls techs/engineers who're from mechanical, electrical, or IT type backgrounds. Or, a combination thereof. I, for instance, have had formal training, real world experience, licensing/certification in all three. That is not to say I'm EXPERT in all three. Nor am I unique. We have others with multidisciplinary backgrounds.

    In any event, during in-house training, I've not noted that any of our pipe fitters ... for instance ... who've become controls specialists, having any problem basically understanding everything being discussed here as regards security. Maybe they don't understand all the bits and bytes details. But they certainly seemed to have no trouble understanding as much as they need to know to be able to use the tools provided by the systems we work with to implement at least basic security steps.

    The folks/installations I've seen who've NOT implemented any such steps, haven't failed to do so because of ignorance. They simply didn't do it ... period.

    Due to laziness. Or lack of concern (after all, it's really the customer's problem). Or they simply don't want to take the extra time and effort. Etc.

    I know some controls outfits who won't take one extra step or do a single extra thing not required/demanded by the customer and/or contract. Period. Their only interest is to get in and get out of the job with a signed check as fast as possible with the least amount done as possible. That is literally their attitude about it. Not one extra step or action that's not required in order to get paid. Period, end of subject.

    Of course no system is totally secure, and can never be against a determined attacker with adequate resources and time.

    But the vast majority of vulnerabilities and vulnerable sites out there exist simply because so many simply don't take the basic steps ... for whatever reason.

    Quote Originally Posted by digo View Post
    The issue of IT merging with Facilities is still an interesting one to watch unfold.
    It should be involved with Facilities ... to some extent. Each side usually representing different sets of abilities/competencies.

    But it can't be a adversarial merger, with each side trying to dominate or take the lead role.






    I'll leave you with the last of the 10 immutable laws of security (from Microsoft):[/QUOTE]
    A site where I stash some stuff that might be interesting to some folks.
    http://cid-0554c074ec47c396.office.l...e.aspx/.Public

  6. #19
    Jeremy, my term for your user is the social element, which encompasses more than the end user. I am not remiss in this consideration as you suggest. I disagree with your assessment that if a system must be used it cannot have a level of security to help combat the social element or if you prefer; the idiocy of the user.

    What I do detect in some comments here is the need to mount a valiant defense of this specific product. A product in which network and access security was not a primary design element of the product. The article states as much from company representatives and the results bear out verification to the conclusion. I view this as not helpful in this discussion of system security as therein will be delusional conclusions. For some of the entities I am aware of access to power generation would be a problem. Access to information on which rooms have lights and HVAC in occupancy is a threat. Would you implement access control with this product? What else may be compromised within the embedded devices themselves or in a supervisory machine? Can anyone describe what do they support with RSA? This is the reasoning behind asking the question as to whether or not the root user has access to the strong key. Why should SSL cost additionally? The commentary of Digo signifies the patching and modifications are ongoing with this product to try to assemble some form of a reasonable solution. The reason this is ongoing is because the product was seriously deficient previously and with upcoming adjustments it will merely be reasonably deficient. There is intent to consider increased hardening of their system. Many others will need to follow in the buildings industry as they do not even consider some of the steps this company is attempting to implement. Once you get into this contest; Always assume you have been compromised or will be compromised. This battle never ends.

  7. #20
    Quote Originally Posted by osiyo View Post
    But the vast majority of vulnerabilities and vulnerable sites out there exist simply because so many simply don't take the basic steps ... for whatever reason.
    Very true... but at the very least we can hope that the bar is raised just slightly to make the systems a bit harder to hack. I mean in all honesty, I was shocked at the number of open systems (with either no password or admin and no password) that I was able to type into google. Im sorry, but the Google Webcrawler should not have admin access to a government site... in any capacity. And the funny part is its an enterprise security installation.

    But I should re-iterate that I think everyone agrees that things like what Im talking about is not Tridium's fault, its the installer's fault. I wonder how long until a security firm hires a niagara developer to help break systems as part of a security audit.
    Last edited by elitecodex; 07-20-2012 at 08:48 AM. Reason: Releasing Tridium of blame

  8. #21
    Join Date
    Apr 2012
    Posts
    94
    Quote Originally Posted by AtticusFinch View Post
    Why should SSL cost additionally?
    Because one has to buy a certificate from certificate authority -- this is how SSL works. You don't know this also? Really?

    P.S. Tridium does not charge for SSL.

  9. #22
    Join Date
    Dec 2006
    Posts
    194
    Quote Originally Posted by pault View Post
    Because one has to buy a certificate from certificate authority -- this is how SSL works. You don't know this also? Really?

    P.S. Tridium does not charge for SSL.

    They charge me. SP-SSL.

    I wont quote the price but it is relatively cheap.

  10. #23
    Join Date
    Apr 2012
    Posts
    94
    Quote Originally Posted by asdf;ljk View Post
    They charge me. SP-SSL.

    I wont quote the price but it is relatively cheap.
    Interesting, I've got it for free (in Europe).

    Have you got a certificate from them?

  11. #24
    Join Date
    Dec 2006
    Posts
    194
    Quote Originally Posted by AtticusFinch View Post
    This Niagara system platform is not designed with security in mind..
    You seem to infer that you know what is "missing" from Tridium's security implementation. Care to elaborate?

  12. #25
    Join Date
    Jul 2012
    Location
    Northern NY
    Posts
    121
    pault,
    it's not so much the certificate it's the fact that you have to have it enabled in the license file and my distributor charges extra for that license. Not sure if all do but I know a few other manufactures also have a part # to enable it in the license that costs extra.

    -Jeremy

  13. #26
    Join Date
    Apr 2012
    Posts
    94
    Quote Originally Posted by kc2dnw View Post
    pault,
    it's not so much the certificate it's the fact that you have to have it enabled in the license file and my distributor charges extra for that license. Not sure if all do but I know a few other manufactures also have a part # to enable it in the license that costs extra.
    -Jeremy
    I've got mine for free in the past, but I've got your point.

    Still I find it unreasonable to demand free SSL from Tridium, because many others web-enabled device vendors do not have this feature at all.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comfortech Show Promo Image

Related Forums

Plumbing Talks | Contractor Magazine
Forums | Electrical Construction & Maintenance (EC&M) Magazine
Comfortech365 Virtual Event