He is like a dry state, not even 1 drink, I was quite dissapointed
Couldnāt afford the Covid charge!
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.
How do these instructions make you feel from Epicor? Instead of them renewing the token, yeah simply change the value to 10hrs.
Sounds like another Episode with Mark is called for.
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.
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. 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.
@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.
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.
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.
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.
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.
When you say IDP, does that specifically refer to Epicorās IDP?
Yea sorry Epicor IDP
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.
Totally agree with Haso here. We should provide access to resources, not the whole network.
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.
what is custom REST. WCF exactly?