Ask the Expert: Unleash your inner IT superhero with EMC’s next-gen customer experience roll-out and ESRS v3 Virtual Edition

JonSharpe wrote: Currently, our PM is set to Always Allow since we do not want to delay EMC should they need to dial in. We are trying to find a balance between satisfying our auditors and allowing EMC to react quickly to events on our arrays. Does EMC have any plans to make the SR# field in ServiceLink required, via PM or otherwise? Could it even be done?

Hi,  we don't have plans to make that field required, but we do have plans to get that information auto populated when possible in addition to making site specific notes for a customer site more prevalent when connecting through ESRS.  I don't however have a date for that as of now.

-Patrick

Yan Faubert wrote: Correct, we want to always deny since remote access to the environment is not allowed. (security policy) We don't want to deploy a Policy Manager (extra server / software to maintain) that basically has one rule which is to Deny all remote access requests.  We want to be able to change the default in ESRS-VE to be 'Always Deny' for remote access.

Hi Yan,  the only way to accomplish this currently would be to install a copy of the PM, configure the ESRS VE to point to it, send the policy to Deny, then simply uninstall the PM.    As long as you leave the IP configured in the ESRS server it will function based on the cached policies and deny the requests.   Any new devices added would also have remote session requests denied.

Depending on the devices you are managing, you could also just simply not deploy them and we won't even have the option to connect.   Feel free to email me directly if you would like to talk about some specifics.   Thank you,

-Patrick

Rash wrote: I've 2 Sites (West and East). There are devices at both locations. Planning to setup ESRS GW at both locations. EAST ESRS GW will have all devices in EAST Coast location. Secondary ESRS GW for EAST Location will be West Coast ESRS GW. Similarly West ESRS GW will have all devices in West Coast location. Secondary ESRS GW for West Locations will be East Coast. I understand there is limitation of 250 devices in each ESRS GW. In above configuration each device will get registered at both locations (Primary and Secondary ESRS GW)? If I've 150 devices at EAST Location and 150 devices at WEST Location that means my ESRS GW and Primary and Secondary location will have 300 devices or 150 devices registered? Isilon clusters each node is considered as a devices and that will make a lot of devices in ESRS GW. Thank you, Rash

Hi,   if you had 2 ESRS servers clustered, that would be a total of 300 devices.   Because devices don't need to be deployed in order to connect home, some customers that have a large number of Isilon nodes don't deploy every single node in order to cut down on the number of managed devices and traffic.  Feel free to email me if you would like to discuss in more detail, thank you!

-Patrick

Correct, we want to always deny since remote access to the environment is not allowed. (security policy)

We don't want to deploy a Policy Manager (extra server / software to maintain) that basically has one rule which is to Deny all remote access requests.  We want to be able to change the default in ESRS-VE to be 'Always Deny' for remote access.

stanley_merkx wrote: Hi, We disabled ESRS some time ago due to the outcome of an external security audit on ESRSv2. From an operational perspective we really miss the flexibility of having remote support via ESRS. However, we are not allowed to re-enable ESRS without a clean bill-of-health from a reputable security auditor. Was ESRSv3 audited by a reputable external security specialist? If so, can we obtain a report of their findings? (If required we are willing to sign an NDA). If EMC does not conduct such audits on ESRS, why not?

We do not have anything we can share publicly at this point but we are in talks with a vendor to provide a customer consumable audit report which would meet this requirement.

That said – below you will find a description of our security posture and testing methodology for ESRS.

The security of ESRS is managed proactively by EMC, cross functionally by EMC Global Services, EMC’s Global Security Organization, EMC’s Product Security Office, the EMC IT development team, and with assistance from 3rd party security testing firms. Focus is placed on managing key control points for ensuring the ESRS application and its supporting infrastructure components are hardened and up-to-date.  EMC maintains and enhances ESRS’s security controls with an on-going security controls testing program.

EMC proactively manages the security posture of ESRS, enlisting its internal security practitioners to evaluate the security controls of ESRS at each layer, and engages a 3rd party security testing firm to conduct an annual end-to-end application security assessment. The scope of the annual application security assessment includes the ESRS application along with infrastructure components that host or enable ESRS.  If vulnerabilities are identified as part of EMC's testing of ESRS, they are first validated by EMC according to industry guidelines before EMC creates, qualifies, and delivers the appropriate response to address the issue. Where possible and depending on the nature of the underlying issue, updates which consist of software patches or releases are streamlined as part of EMC's planned application release schedule in order to mitigate the impact on your business environment. EMC communicates available ESRS updates to customers via EMC security advisories, available for subscription at https://support.emc.com.

The ESRS-VE also takes advantage of “vLM” – which allows customers to accept updates as they become available rather than waiting for manual patch containing our next quarterly version, and allows us to make bug fixes and security updates available in a much more agile and timely fashion.

Please contact me directly at andy.sell@emc.com.

I have a customer who has hundreds of VNX in their environment. They need an efficient and scalable way to implement ESRS. Any ideas on how this can be done?

ESRS: Apache Tomcat 7.0.60 upgrade to resolve FREAK vulnerability

We have a Security Exception Letter (SEL) for this vulnerability.  It is my understanding that EMC can upgrade Tomcat to version 7.0.57, but not 7.0.60.  We were also told the problem is not fixed in 7.0.57.  Our PCI auditor wants something in writing from EMC to be put in the SEL as to why we can’t migrate to 7.0.60 to address this vulnerability and when a fix (7.0.60) will be available. 

Sounds to me like I need an expert to help answer these questions. 

christopher.a.wintheiser wrote: ESRS: Apache Tomcat 7.0.60 upgrade to resolve FREAK vulnerability We have a Security Exception Letter (SEL) for this vulnerability.  It is my understanding that EMC can upgrade Tomcat to version 7.0.57, but not 7.0.60.  We were also told the problem is not fixed in 7.0.57.  Our PCI auditor wants something in writing from EMC to be put in the SEL as to why we can’t migrate to 7.0.60 to address this vulnerability and when a fix (7.0.60) will be available.  Sounds to me like I need an expert to help answer these questions.

Hi Chris,  I've already been contacted regarding this and am working on a Tomcat upgrade and information about what is and isn't affected by FREAK with ESRS.   Thank you,

edit:

I've updated the KB article with the new version of Tomcat:

201024 : ESRS: Upgrading the embedded Tomcat 7 service in ESRS Policy Manager 6.6            

https://support.emc.com/kb/201024

As for the FREAK vulnerability, the Policy Manager 6.6 software and the ESRS VE both are not susceptible to FREAK as neither of them use the RSA_EXPORT ciphers.  I have run the FREAK tests against a default PM install as well as one with the 7.0.65 Tomcat upgrade and both came back clean.   Please email me directly if you are seeing something different and we'll take it from there.   Thank you!

-Patrick

While I do like the virtual edition, what are the plans for the non virtual version? Currently we are using 2.28 and 2.26.

We have sites where we cant install the virtual edition. Are there plans to get the non virtual edition to the 3.x version? Will it support Windows 2012?

Thanks

Mark

Hi Andy,

Thanks for your reply.

I have forwarded it to our in-house security specialist (in cc on this email). I expect he may get in touch with you directly if he has additional questions...

Re,

Stanley.

Sent with Good Work (www.good.com)

From: DASell

Date: vrijdag 20 nov. 2015 15:46

To: Merkx, S.J. (Stanley)

Subject: Re: - Ask the Expert: Unleash your inner IT superhero with EMC’s next-gen customer experience roll-out and ESRS v3 Virtual Edition

ECN

Ask the Expert: Unleash your inner IT superhero with EMC’s next-gen customer experience roll-out and ESRS v3 Virtual Edition

reply from Andy Sell in EMC Secure Remote Services Forum - View the full discussion

Windows 2012 includes Hyper-V, so that can also be used for an ESRS 3.x VE install.  There shouldn't be too much of an issue getting VE installed on 2012 then, or was there a reason for not being able to implement?  There are many advantages to have 3.x/VE running in its own environment.

We are currently running a version 2 release and it is not PCI compliant. Does ESRS V3 support TLS 1.2 for PCI compliance? Is there any reason we can not upgrade to V3?

Does ESRS V3 support TLS 1.2 for PCI compliance? We are currently running a version 2 release.

This Ask the Expert event has officially ended, but don't let that retract you from asking more questions. At this point our SME are still welcomed to answer and continue the discussion though not required. Here is where we ask our community members to chime in and assist other users if they're able to provide information.

Many thanks to our SMEs who selflessly made themselves available to answer questions. We also appreciate our users for taking part of the discussion and ask so many interesting questions.

ATE events are made for your benefit as members of ECN. If you’re interested in pitching a topic or Subject Matter Experts we would be interested in hearing it. To learn more on what it takes to start an event please visit our Ask the Expert Program Space on ECN.

I am trying to configure ESRS 3.14 and have been having an issue connecting to EMC.  I have the ESRS server internal port 443 is allowed, but port 8443 is not.  I was told port 8443 is required for the original configuration, but technical docs mention that it is not required.   I log in with my credentials, select site ID, then select next and it authorizes and give me an error BAD request, per knowledge base it mentions to register SUSE server with command suse_register, I get an error when running that command.   Any help would be appreciated