Series 1 EpiSode 5: ERP Security with Mark Wonsil

He is like a dry state, not even 1 drink, I was quite dissapointed :frowning:

2 Likes

Couldnā€™t afford the Covid charge! :thinking:

2 Likes

@Mark_Wonsil , you have an office in Iran, really :wink:

1 Like

I had a talk the next morning about implementing Zero Trust in Kinetic environments. After seeing the effects of a few ā€œeventsā€ up close, Iā€™ve become quite passionate about security.

1 Like

How do these instructions make you feel from Epicor? Instead of them renewing the token, yeah simply change the value to 10hrs.

2 Likes

Sounds like another Episode with Mark is called for. :wink:

1 Like

As a technical consultant, Iā€™ve been worrying about this for some time and particularly REST. For my on-prem customers who want to expose Epicor to the web (for ECC, T&E or similar), Iā€™ve recommended a stand alone appserver on a server in the DMZ with an Access Scope defined to only allow ECC stuff. I gave one customer a real shock when they gave me T&E access and I sent them a full list of their BAQs.

But Iā€™d never considered Cloud (I only deal in on-prem) where, as far as I am aware, everything has to be exposed to the web. This scared me, but then I might be wrong due to my lack of exposure to cloud customers.

I am formulating some ideas around how to take menu security and translate it to service security, but curious as to what the demand would be around this, before I invest too much time. One approach is Kinetic only, but I also have an approach for on-prem ERP10.

I am not a great fan of the current Menu security (which feels to have taken a backward step with the latest Kinetic screens splitting Menu and Security out), and have previously provided customers with a spreadsheet for them to assign groups, which can then be manipulated a little to give something you can use to update security via DMT. The advantage of this is that you can apply in Test, before applying the same thing to live. This would steer me towards a similar DMT sheet for process security.

James.

2 Likes

Welcome James.

Yes, Menu Security, which hasnā€™t changed since the days of Vantage, has never been enough to properly secure an environment IMHO. One should use both Field and Service security to lock down the business objects and BAQs. Data Masking on read-only fields (of all types) would make this a much easier job as getting too aggressive with Service Security may break standard functionality.

Also, all companies, on prem or in the cloud, should use an identity provider like Epicorā€™s IDP or Azure AD. This is far more security than Basic Authentication. Epicor and Kinetic have been web applications since E10 running on IIS.

Unless a company has no wi-fi (and prevents phones on their networks), doesnā€™t run their own email server, and doesnā€™t have laptops that leave the building, on-prem is just as harrowing as the cloud. For those of us in the business for a long time, we have a false sense of security of having the data in the building - this, despite every malware outbreak in the news in on-prem. :person_shrugging: Cloud data centers are far more secure and have better security hygiene and resiliency than just about every Epicor customer out there.

Companies should take a Zero Trust approach with all of their systems and not just ERP: Verifying each transaction, use least privilege, and assume breach.

1 Like

@Mark_Wonsil we are implementing ZScaler ZPA (Private Access) VPN which is Zero Trust. One step in the right direction. For those on-prem, you should consider it, we are moving away from Palo Alto Global Protect, despite forced tunneling.

2 Likes

Focussing on the Epicor security, the more I think about it the more Service Security has to be used aggressively.

Menu security probably was enough in the days of AvantĆ© (I do go that far back), but I agree it is inadequate now. And in Vantage / E9 days, I used to believe that employees were trusted (on the basis you wouldnā€™t employ them otherwise).

Then REST came along and I started to worry - but it was mainly only available on the LAN, so it was a ā€˜lesserā€™ risk, did customers worry enough - probably not. And, in the early days, you could still switch it off.

But, I believe, for cloud customers all REST services are accessible from anywhere on the internet, if you have the URL and a User / Password. Give me the URL and credentials so I can sign in to any of the mobile apps, and I have the keys to the kingdom. When I realised that I really started to worry. I admit it took me a while - but I never deal with cloud customers. And then I found nice youTube videos telling anyone how to use REST with Epicor.

You mention least privilege but also suggest we donā€™t get too aggressive with Service Security. Surely we canā€™t be scared of using it, and (alongside BAQ security), we have to go with least privilege. It certainly shouldnā€™t ā€œbreakā€ standard functionality, but it may halt someoneā€™s work, in which case we need to allow them access to that method / service. If it does break functionality - that is clearly a bug.

This is why I am thinking about developing some tooling to translate Menu Security (which is vaguely understandable to users) to process security. For on prem customers at ERP10, I have another approach which is likely to get 99% of the way. But, and I guess this is why I am posting here, is it really what customers need/want?

As for relying on an IdP, I have reservations which I donā€™t want to discuss on an open(ish) forum.

2 Likes

I understand you not wanting to discuss critical details on a semi-public forum. But I am very curious about why you have these reservations. I am pretty new to the security side. Honestly, the last 5 years seems to have flipped security on its head. Everyone seems to wants identity providers now. If you can offer any of the concerns you have about using an IDP, I am sure I am not the only one that would be interested. If nothing else, it could lead to an informative discussion.

1 Like

There isnā€™t a problem with using an IdP, my concern is related to relying on them to provide extra security. But itā€™s also theoretical at the moment; as I donā€™t deal with cloud customers, I donā€™t know for sure.

1 Like

Epicor IDP was written using state of the art frameworks at the time I would posture that IDP is as good as using Azure AD or another 3rd party identity provider. Azure has a edge on it because it also functions as a global identity provider and can rely on context which may not be available to IDP.

Historical data on location, pattern matching etc however if Azure Ad isnā€™t available I would go with IDP in a heartbeat over basic auth

Separating Authentication from Authorization is one of the most essential steps in keeping a system secure.

6 Likes

When you say IDP, does that specifically refer to Epicorā€™s IDP?

1 Like

Yea sorry Epicor IDP

2 Likes

Yes, you are describing the issue with Basic Authentication with a single factor. That is why Microsoft does not allow this for retrieving email as of this month. And this situation is true for all cloud email providers, for all cloud HR and Payroll providers, for all government agency websites, etc. This is why we ALL need to move away from Basic Authentication and towards an Identity Provider. As Jose mentioned, I would take IdP over Basic Auth any day of the week. Azure AD brings to the table extra capabilities like conditional access, Privilege Access Management, Auditing, etc.

We need to shed the belief that just because a system is behind a firewall that it is safer than the cloud. While there are occasionally bugs in firewalls, VPNs, Exchange Servers, etc. attackers very rarely ā€œbreak inā€ - they usually just log in. Itā€™s far easier. The vast majority of compromises begin with a single event, that leads to another, and so on.

  • An attachment opened from email
  • A file downloaded from a site
  • A laptop brought home and the user installs a free version of something the company wouldnā€™t pay for
  • A click on link that hooks a browser and steals tokens to current sessions
  • A supply chain component that is vulnerable running in a program that you donā€™t even know used it
  • A car in the parking lot sniffs unencrypted network traffic for plain text passwords

Once thereā€™s a tiny foothold, a program inspects the network to see whatā€™s there and at what versions. Got Windows Server 2008 R2 out there? Great. Got more recent servers missing patches. Excellent. Running Apache Tomcat? Wonderful. Using Active Directory? Exploit a Pass The Hash exploit to exfiltrate passwords. Now download the known exploits for each of these and ā€œall your severs are now belong to us.ā€ Data is then exfiltrated, and then encrypted, or even just destroyed.

Iā€™m saying that Service Security alone is too crude a tool. Itā€™s an important part of a security strategy, but it alone is not enough. Letā€™s say I want to block access to cost information on a part. Can we just block Part.GetByID? No, there are other areas on the part that users will need to see. One needs to also look at Field Security and maybe some BPMs for finer control.

Speaking of BPMs and Functions, any direct access to the database through code using DBContext (or ODBC) is completely free from any of these security controls. Consider that access in oneā€™s least privilege calculus.

Oh, my yes. The customers need it even if they donā€™t realize they want it yet. There is a lot of room for improvement for setting up security in a Kinetic Implementation. Ask any companies who have to comply with US SOX regulations. As I mentioned above, I have been thinking about how to integrate Azure AD more tightly to ERP security. We need more discussion around this as a community for sure.

2 Likes

Totally agree with Haso here. We should provide access to resources, not the whole network.

2 Likes

Yeahā€¦ Weā€™ve avoided it forever but as I think @bderuvo said at one point in this video, we had a bit of a ā€œholy crapā€ moment once we started using REST more and realized any user could access any of these endpointsā€¦ Weā€™re on prem and keep Epicor very guarded from the WAN but I really donā€™t like that the only thing stopping a user from going to Postman, etc. and making REST calls from within the LAN is a lack of knowledge.

I went looking for an easy button that would let me say only these certain users (integration accounts) can make REST calls, but I can see why we canā€™t just do that as Kinetic browser, EKW mobile apps, etc. are all making REST callsā€¦ Even @Bart_Elia had some posts explaining that REST security isnā€™t really different than WCF, and I see that now, but maybe I am more concerned now because REST through a browser is more ā€œaccessibleā€ to a savvy but non-IT user than writing C# is. @James_Stubbs , I may be interested in this if you have something good developed:

But even if we do go through the whole ordeal of Service Security implementation, a user can still go to a browser and make REST calls. They can only access certain BOs, which is much better, but still not exactly what weā€™d like. So Iā€™m still hanging onto hope for this ā€œeasy buttonā€, maybe I will enter a Kinetic Idea. I donā€™t know exactly what to ask for but it would be something like ā€œsecurity feature to block ā€˜customā€™ REST, WCF, etc. calls to the server unless user account has permission grantedā€. And the feature would know that Kinetic browser or EKW mobile app or any future Epicor app is not ā€œcustomā€.

Maybe @Mark_Wonsil or @Olga can help us figure out what makes sense to ask forā€¦

Are you asking that users not make REST calls at all? With Kinetic UX thatā€™s not really an option, but if you use Field / Service security they would only have access to those BOā€™s you give them access to.

I agree that the entire security model of Epicor needs a revamp from the ground up.

1 Like

what is custom REST. WCF exactly?