Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
A funny thing happened to me last night. Why do funny things always happen when I have time to think?
I was manually copying over birthdays from my Exchange calendar to a Google calendar. Pretty brainless work so my mind was wandering. And, I realized... if I were a little less careful and made this public, I’d put 100 or so identities at risk.
Let me explain.
I’m a fanatic about birthdays. Not sure how it evolved but I actually receive a thank you note at the end of the year from Mr. Hallmark (kidding, of course, but I should!). I figure life goes by so quickly without keeping in touch with people, so the least I can do is catch up once a year on people’s birthdays. And in conversation, if someone’s birthday comes up or if someone mentions the birth of a child, I jot it down and put it in my calendar. I put it in with a 7 day alert which reminds me to get and mail a card.
It’s always the first one there.
So as I was entering birthday’s last night, I would enter something like:
David Bressler’s Birthday (’67)
David Bressler’s Birthday (’67)
And if I made this a public calendar, everyone could easily find my birthday. Why is this a problem?
Well, I still don’t know Dan’s -- it’s a mystery. Even his Facebook page has the wrong one! Why? Because he’s worried about identity theft. OK, but what if I did know his birthday and published it? Well, years worth of data security implemented by Dan would be tossed out because one idiot (me) accidentally hit “public” instead of “private” on a Google calendar.
SOA What? Think about it for a second. Companies spend all sorts of effort on keeping data secure, yet it’s really about people and process as well. Just like developer time governance.
Even more importantly, however, is the idea of what’s at stake. Application level security was relatively easy (IMO) - compared to service-level security. I mean, you install an application and you usually know. However, services are a different story. Services are often there as API’s to applications; though the application installers aren’t usually considering them. Worse, any developer can create and expose a web service and an admin would hardly know it’s there. This has the potential to expose data to anyone patient enough to try the default endpoints for packaged services. And, before you disagree... how many Sales Engineers are successful “breaking into” customer systems with default passwords? More than anyone would care to admit! Besides, a lot of security problems are from within an organization, so when administrators don’t know what’s there, they can’t possibly manage the risk.
My point? I admit, I’m rambling a bit... still trying to break through some writer's block. My point is that you’d better know what’s going on, not think you know. To do that, automatic discovery is a critical requirement to any runtime SOA governance evaluation with your SOA infrastructure.
View all posts from david bressler on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.