[...] given that a Defect doesn't have business value like a story?
I disagree with this. As a user, I want my software product to work and behave as intended. A known defect goes against this. Accumulate and ignore enough defects and sooner or later your customer(s) will stop using your product and use someone else's instead.
This is something known as retained revenue1, which includes customer(s) that would leave if something the customer wants/needs is not done. This is often mentioned in terms of features, but it can also include defects. (Can you honestly claim your product has some feature X if said feature is broken? I don't think so.)
Since it is assumed that when a feature or story is accepted as "done" it works as expected, it's perfectly valid to create another story and estimate it in the same way as you normally do, especially if the defect is discovered by the customer(s) after release. If the defect is known prior to release, then perhaps the Product Owner should've rejected the "done" status for the story and moved it back to "In Progress" or a equivalent status, but not call it "done".
Should we have something different from story points, for example,
No. Just treat it like any other story in your team's backlog with a size estimate for its effort/complexity and a priority that's relative to other stories.
Since defects are an example of "Technical Debt", and bugs become more expensive to fix the more their resolution is delayed after being discovered, the team and P.O. should consider giving defects a slightly higher priority. What you use to determine this priority (e.g. visibility, customer annoyance, something else?) should be up to your team.
Just my 2 cents.
1 Agile Estimation and Planning, by M. Cohn